Repository is missing tags

[EvaSDK]

It looks like while migrating from gnome infrastructure to github, all tags were lost.

Please either import back the tags from gnome (or push new ones if you want to change their syntax) so that release points are more easy to spot.

[tstriker]

thought about tags but i don't see much value in keeping them. the old ones won't change and won't be maintained (last release what - 2 years ago?).
will be tagging and branching the next releases however

[EvaSDK]

They might not be useful by themselves but they are of great value for downstream packages to properly get the point of release and prepare their patches. For example, it would be make it easier for a downstream packager like myself to checkout last release and get translation updates only. It's just a part of the history of the project :).

Thanks for considering anyway.

[tstriker]

humm humm.

[tstriker]

half finished comment - i guess i need more input from you - would it be enough to just add the last known hamster release as a tag? perhaps you can point me to some packagers docu so i can learn more and make hamster package friendlier.

another question i've been wondering is, what would be a friendly way to inform packagers about a new version - any ideas?

thank you for your time!

[EvaSDK]

For me, getting at least the last known hamster release tag would be enough as I mostly would like to evaluate work that has been ongoing since last release and eventually prepare a snapshot based on beta version that has been tagged like gnome projects do for example (x.91.0, x.92.0, etc).

I have no documentation handy, but for example, packagers do appreciate being able to checkout an upstream repo, create a branch from the release they are currently working on, and cherry-pick patches fixing issues reported by user if there is no newer release.

It is also easier to rebase not-yet-merged work or downstream specific patches when there is a tag to rebase to. It avoids searching through history of the repository since packagers, much like upstream, does not have extensible time to work with :)

There is most likely other examples of how tags and history preservation help downstream and upstream work hand in hand but you most likely get the idea now.

As for release notification, github provides watch feature which is a good start. Debian and Gentoo have tools to scan through various hosting systems to get the last release notifications but using the usual means is also a good thing: mailing list, blog posts (maybe specific RSS feed), irc channel, etc.

One last thing, I know this is a lost practice for most upstream that switched to dvcs, but providing a news file summing up most important changes since last release is really something I love. This can obviously be replaced by one of the other communication means listed above if it is easy to link to the precise information and is stable to access over time.

thanks for reading :)

[marvil07]

Some information on the debian upstream guide:
http://wiki.debian.org/UpstreamGuide

[tstriker]

added a tag where we branched off to 2_91_03. It's a rough cut-off point really and from what i've seen at some point the packages where built with timestamps from git.
Thanks for your input guys - i'll see what i can do to make hamster a pleasant and easy packaging experience 🍰

[tstriker]

releases are now being tagged proper(it's also pretty much the extent of a "release")

[EvaSDK]

Thanks.