Re: Tagging stable releases
- From
Andreas Ericsson <ae@op5.se>
- Date
- Apr 15, 2009, 08:33 UTC
- Message-ID
- <49E59BC9.5060906@op5.se>
- In-Reply-To
- <23045562.post@talk.nabble.com>
Asaf wrote:
Show 13 quoted lines
> Hello, > > I'm creating many branches, checkout code, make changes, etc.. > At the end, I always merge these branches to the master branch and delete > them when I finish, > > > At the point where my local master repo seems to be stable, I push the > changes to an origin repo that is public. > > > I guess this is a standard cycle, right? >
There are many standard cycles. This is one of them :)
> > What I'm confused about is how to tag correctly versions that are stable, > Should I locally just add a tag and push the tag to the public repo? >
Yes.
> > Is it enough to use a lightweight tagging for tagging a certain commit as a > release?
That's up to you. I'd recommend against it, because the default update hooks disallow lightweight tags from being pushed.
We use signed tags for all releases, so we know and can verify who tagged what. I guess it's a corporate thing to desire the capability of saying "It was *HIS* fault, not mine!", and signing a tag means you sign the tree as it is at sign-time with all the history leading up to it.
> Is it possible later on to checkout a tag, make a change and push the change > into the tagged version? >
No. Consider published tags immutable in git, please. Imagine the confusion and headache you'd get from bug-reports if version 4.6.3 is not the same code everywhere. What you can and should do is to: * create a branch at the location of the old tag * make whatever changes are necessary * test as necessary * cut a new release with your changes
At $dayjob, we have an update hook preventing tags without the "-beta$X" suffix from being pushed unless it points to an already tagged commit, so our workflow goes like this: 1 hack hack hack 2 beta-tag 3 buildbot builds beta package and sends it off to qa 4 qa responds with "ok to release" 5 we stable-tag the exact same version we shipped to qa 6 buildbot builds stable tag and copies it to "to-be-released" directory 7 release-manager pushes the release-button once changelogs and stuff are in place
If qa says "hey, it's broken", we repeat steps 1-4 until we get "ok". If we accidentally tag something as stable while it's broken, we *can* go back and re-create the tag before step 7 is done. We've found out that it's usually more trouble than it's worth though, because there's always a small uncertainty that qa gets the new code on all his machines, and the bug we nearly released may not always show up on all platforms.
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace.