Tagging stable releases

Tagging stable releases

[Asaf]

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?


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?


Is it enough to use a lightweight tagging for tagging a certain commit as a
release?
Is it possible later on to checkout a tag, make a change and push the change
into the tagged version?


Many thanks,


Asaf.
-- 
View this message in context: http://www.nabble.com/Tagging-stable-releases-tp23045562p23045562.html
Sent from the git mailing list archive at Nabble.com.

Re: Tagging stable releases

[Andreas Ericsson]

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.

Re: Tagging stable releases

[Stefan Näwe]

Andreas Ericsson <ae <at> op5.se> writes:

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

You've been talking about using git at your $dayjob quite often.
Any chance to share some of your 'infrastructure' (like hooks, e.g.) ?

Thanks

Stefan

Re: Tagging stable releases

[Andreas Ericsson]

Stefan Näwe wrote:
> 
> You've been talking about using git at your $dayjob quite often.
> Any chance to share some of your 'infrastructure' (like hooks, e.g.) ?
> 

I could, but it would largely be a waste of time. We're still using a
more or less the original example update hook (which I wrote) at work,
and that's pretty much it. Fortunately, we've never run into "out of
diskspace" error or something like that, so it's always worked
perfectly for us.

The, for us, major addendum is a part of the script which appends
the latest pushed commit to a file. We have a build-bot cron-script
triggered every 5 minutes which builds tarballs and RPM's from the
triggering commit and sends email to developers on errors or on
error recovery (a sort of poor man's continuous integration), but
highly effective all the same.

Apart from the tag-dance, we also try to keep our history as
bisectable as possible, which means we rebase a lot and resolve
conflicts in single-parent commits as far as is humanly possible.
This stems from the fact that bisection is really only complicated
when it happens to land on a multi-parent commit where neither of
the parent-chains introduced the breakage (ie, the resolution of
the merge-conflicts is at fault). I was interviewed about this
in some online magazine or other, though I can't quite recall the
URL right now. What with us having a partner-event with free beer
and wine at the office atm, I'm surprised I haven't added a ton
of spelling errors already :P

The fact that I'm at the same time a development spider (looking
at everything) and at the same time one of the top 100 or so
people in the world that knows how and why git works the way it
does helps things a lot in our end, and made it possible for us
to adopt git early (around february 2006, afair) as the company
scm of choice.

Sorry, but we're not a large enough in-house development team
to have communication problems. I resolve most of the merge
conflicts (for small changes, usually by telling the person
who tried to push that he needs to re-do his/her changes on top
of the latest pushed development branch).

We do use topic-branches extensively, but only for multi-commit
fixes. Otherwise it's usually committed straight to 'master' or
whatever our 'hackaway' branch is named. I cherry-pick or merge
bugfixes back to our equivalence of 'maint' (which differs from
repo to repo, as we have nearly 300 of the little buggers).

Testing is used rather extensively, but nearly all our tests
have grown from the need to bisect. In other words, our tests
make sure the API they're trying to test actually exist before
they attempt to use them. If they don't, they respond "git
bisect bad". If we didn't ask for that test implicitly, it
responds in a way that makes test pass but the testsuite fail
for builds. It's not complicated, but it is rather tailor-made.

Ah well. Without a more specific question I'm afraid I won't 
be able to give a better answer. If you're working for a
company that produces products from a multitude of different
software projects (like we do) and your product is largely
RPM-based, I'll send you our build-scripts and whatnot.
Unless I get a specific question about it though, I won't
bother the rest of the list with a bunch of junk they'll
never bother about.

Happy gitting :)

-- 
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.

Re: Tagging stable releases

[Tim Mazid]

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?
> 

You don't need to merge everything back into master or delete branches.
When you 'git push', it only pushes remote tracking branches. (Branches that
you fetched from that repo).
If you do 'git push --all', it will push all your branches to the repo.
If you do 'git push REMOTE-REPO BRANCH', it will push just that branch. You
can, of course, list multiple branches.


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

Yup.


Asaf wrote:
> 
> Is it enough to use a lightweight tagging for tagging a certain commit as
> a release?
> 

Yes, but signing it makes others feel more confident, and if you at least
annotate, you can provide some sort of description.


Asaf wrote:
> 
> Is it possible later on to checkout a tag, make a change and push the
> change into the tagged version?
> 

Once again, yup, just do 'git checkout TAG'. Though you may want to do 'git
checkout -b NEW-BRANCH TAG'.

Good luck,
Tim.
-- 
View this message in context: http://www.nabble.com/Tagging-stable-releases-tp23045562p26093620.html
Sent from the git mailing list archive at Nabble.com.