Repository is missing tags #36

EvaSDK opened this Issue Oct 11, 2012 · 9 comments


None yet
3 participants

EvaSDK commented Oct 11, 2012

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 commented Oct 11, 2012

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

@tstriker tstriker closed this Oct 11, 2012

EvaSDK commented Oct 11, 2012

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 commented Oct 11, 2012

humm humm.

@tstriker tstriker reopened this Oct 11, 2012


tstriker commented Oct 11, 2012

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 commented Oct 12, 2012

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 :)

Some information on the debian upstream guide:


tstriker commented Oct 13, 2012

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 commented Feb 9, 2014

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

@tstriker tstriker closed this Feb 9, 2014

EvaSDK commented Feb 10, 2014


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment