Re: Tagging stable releases

[Andreas Ericsson <ae@op5.se>]

Asaf wrote:
> 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.