Tagging stable releases

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.

Asaf wrote:

There are many standard cycles. This is one of them :)

Yes.

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.

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 <ae <at> op5.se> writes:

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

Stefan Näwe wrote:

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

Asaf wrote:

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:

Yup.

Asaf wrote:

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

Asaf wrote:

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

Good luck, Tim.