{"thread":{"id":"18868","subject":"Tagging stable releases","startedAt":"2009-04-14T18:43:55Z","lastAt":"2009-10-28T12:17:13Z","messageCount":5,"participants":["Asaf","Andreas Ericsson","Stefan Näwe","Tim Mazid"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"111301","messageId":"23045562.post@talk.nabble.com","threadId":"18868","inReplyTo":null,"subject":"Tagging stable releases","fromName":"Asaf","fromEmail":"asafs2000@yahoo.com","sentAt":"2009-04-14T18:43:55Z","receivedAt":"2009-04-14T18:43:55Z","isPatch":false,"sender":{"key":"asafs2000@yahoo.com","avatar":null},"body":"\nHello,\n\nI'm creating many branches, checkout code, make changes, etc..\nAt the end, I always merge these branches to the master branch and delete\nthem when I finish,\n\n\nAt the point where my local master repo seems to be stable, I push the\nchanges to an origin repo that is public.\n\n\nI guess this is a standard cycle, right?\n\n\nWhat I'm confused about is how to tag correctly versions that are stable,\nShould I locally just add a tag and push the tag to the public repo?\n\n\nIs it enough to use a lightweight tagging for tagging a certain commit as a\nrelease?\nIs it possible later on to checkout a tag, make a change and push the change\ninto the tagged version?\n\n\nMany thanks,\n\n\nAsaf.\n-- \nView this message in context: http://www.nabble.com/Tagging-stable-releases-tp23045562p23045562.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"111346","messageId":"49E59BC9.5060906@op5.se","threadId":"18868","inReplyTo":"23045562.post@talk.nabble.com","subject":"Re: Tagging stable releases","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-04-15T08:33:13Z","receivedAt":"2009-04-15T08:33:13Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Asaf wrote:\n> Hello,\n> \n> I'm creating many branches, checkout code, make changes, etc..\n> At the end, I always merge these branches to the master branch and delete\n> them when I finish,\n> \n> \n> At the point where my local master repo seems to be stable, I push the\n> changes to an origin repo that is public.\n> \n> \n> I guess this is a standard cycle, right?\n> \n\nThere are many standard cycles. This is one of them :)\n\n> \n> What I'm confused about is how to tag correctly versions that are stable,\n> Should I locally just add a tag and push the tag to the public repo?\n> \n\nYes.\n\n> \n> Is it enough to use a lightweight tagging for tagging a certain commit as a\n> release?\n\nThat's up to you. I'd recommend against it, because the default update hooks\ndisallow lightweight tags from being pushed.\n\nWe use signed tags for all releases, so we know and can verify who tagged\nwhat. I guess it's a corporate thing to desire the capability of saying\n\"It was *HIS* fault, not mine!\", and signing a tag means you sign the tree\nas it is at sign-time with all the history leading up to it.\n\n> Is it possible later on to checkout a tag, make a change and push the change\n> into the tagged version?\n> \n\nNo. Consider published tags immutable in git, please. Imagine the confusion\nand headache you'd get from bug-reports if version 4.6.3 is not the same\ncode everywhere. What you can and should do is to:\n* create a branch at the location of the old tag\n* make whatever changes are necessary\n* test as necessary\n* cut a new release with your changes\n\nAt $dayjob, we have an update hook preventing tags without the \"-beta$X\"\nsuffix from being pushed unless it points to an already tagged commit,\nso our workflow goes like this:\n1 hack hack hack\n2 beta-tag\n3 buildbot builds beta package and sends it off to qa\n4 qa responds with \"ok to release\"\n5 we stable-tag the exact same version we shipped to qa\n6 buildbot builds stable tag and copies it to \"to-be-released\" directory\n7 release-manager pushes the release-button once changelogs and stuff\n  are in place\n\nIf qa says \"hey, it's broken\", we repeat steps 1-4 until we get \"ok\".\nIf we accidentally tag something as stable while it's broken, we *can*\ngo back and re-create the tag before step 7 is done. We've found out\nthat it's usually more trouble than it's worth though, because there's\nalways a small uncertainty that qa gets the new code on all his machines,\nand the bug we nearly released may not always show up on all platforms.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"111369","messageId":"loom.20090415T161255-114@post.gmane.org","threadId":"18868","inReplyTo":"49E59BC9.5060906@op5.se","subject":"Re: Tagging stable releases","fromName":"Stefan Näwe","fromEmail":"stefan.naewe+git@gmail.com","sentAt":"2009-04-15T16:15:51Z","receivedAt":"2009-04-15T16:15:51Z","isPatch":false,"sender":{"key":"stefan.naewe+git@gmail.com","avatar":"https://gravatar.com/avatar/ff9c89e7b42e5c7f494ef0f19ac9bde6693fb6465356711b8d4ed47d2108dd46?d=mp&s=160"},"body":"Andreas Ericsson <ae <at> op5.se> writes:\n\n> \n> At $dayjob, we have an update hook preventing tags without the \"-beta$X\"\n> suffix from being pushed unless it points to an already tagged commit,\n> so our workflow goes like this:\n> 1 hack hack hack\n> 2 beta-tag\n> 3 buildbot builds beta package and sends it off to qa\n> 4 qa responds with \"ok to release\"\n> 5 we stable-tag the exact same version we shipped to qa\n> 6 buildbot builds stable tag and copies it to \"to-be-released\" directory\n> 7 release-manager pushes the release-button once changelogs and stuff\n>   are in place\n\nYou've been talking about using git at your $dayjob quite often.\nAny chance to share some of your 'infrastructure' (like hooks, e.g.) ?\n\nThanks\n\nStefan\n"},{"id":"111389","messageId":"49E62181.6040202@op5.se","threadId":"18868","inReplyTo":"loom.20090415T161255-114@post.gmane.org","subject":"Re: Tagging stable releases","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-04-15T18:03:45Z","receivedAt":"2009-04-15T18:03:45Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Stefan Näwe wrote:\n> \n> You've been talking about using git at your $dayjob quite often.\n> Any chance to share some of your 'infrastructure' (like hooks, e.g.) ?\n> \n\nI could, but it would largely be a waste of time. We're still using a\nmore or less the original example update hook (which I wrote) at work,\nand that's pretty much it. Fortunately, we've never run into \"out of\ndiskspace\" error or something like that, so it's always worked\nperfectly for us.\n\nThe, for us, major addendum is a part of the script which appends\nthe latest pushed commit to a file. We have a build-bot cron-script\ntriggered every 5 minutes which builds tarballs and RPM's from the\ntriggering commit and sends email to developers on errors or on\nerror recovery (a sort of poor man's continuous integration), but\nhighly effective all the same.\n\nApart from the tag-dance, we also try to keep our history as\nbisectable as possible, which means we rebase a lot and resolve\nconflicts in single-parent commits as far as is humanly possible.\nThis stems from the fact that bisection is really only complicated\nwhen it happens to land on a multi-parent commit where neither of\nthe parent-chains introduced the breakage (ie, the resolution of\nthe merge-conflicts is at fault). I was interviewed about this\nin some online magazine or other, though I can't quite recall the\nURL right now. What with us having a partner-event with free beer\nand wine at the office atm, I'm surprised I haven't added a ton\nof spelling errors already :P\n\nThe fact that I'm at the same time a development spider (looking\nat everything) and at the same time one of the top 100 or so\npeople in the world that knows how and why git works the way it\ndoes helps things a lot in our end, and made it possible for us\nto adopt git early (around february 2006, afair) as the company\nscm of choice.\n\nSorry, but we're not a large enough in-house development team\nto have communication problems. I resolve most of the merge\nconflicts (for small changes, usually by telling the person\nwho tried to push that he needs to re-do his/her changes on top\nof the latest pushed development branch).\n\nWe do use topic-branches extensively, but only for multi-commit\nfixes. Otherwise it's usually committed straight to 'master' or\nwhatever our 'hackaway' branch is named. I cherry-pick or merge\nbugfixes back to our equivalence of 'maint' (which differs from\nrepo to repo, as we have nearly 300 of the little buggers).\n\nTesting is used rather extensively, but nearly all our tests\nhave grown from the need to bisect. In other words, our tests\nmake sure the API they're trying to test actually exist before\nthey attempt to use them. If they don't, they respond \"git\nbisect bad\". If we didn't ask for that test implicitly, it\nresponds in a way that makes test pass but the testsuite fail\nfor builds. It's not complicated, but it is rather tailor-made.\n\nAh well. Without a more specific question I'm afraid I won't \nbe able to give a better answer. If you're working for a\ncompany that produces products from a multitude of different\nsoftware projects (like we do) and your product is largely\nRPM-based, I'll send you our build-scripts and whatnot.\nUnless I get a specific question about it though, I won't\nbother the rest of the list with a bunch of junk they'll\nnever bother about.\n\nHappy gitting :)\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"126133","messageId":"26093620.post@talk.nabble.com","threadId":"18868","inReplyTo":"23045562.post@talk.nabble.com","subject":"Re: Tagging stable releases","fromName":"Tim Mazid","fromEmail":"timmazid@hotmail.com","sentAt":"2009-10-28T12:17:13Z","receivedAt":"2009-10-28T12:17:13Z","isPatch":false,"sender":{"key":"timmazid@hotmail.com","avatar":null},"body":"\n\nAsaf wrote:\n> \n> Hello,\n> \n> I'm creating many branches, checkout code, make changes, etc..\n> At the end, I always merge these branches to the master branch and delete\n> them when I finish,\n> \n> \n> At the point where my local master repo seems to be stable, I push the\n> changes to an origin repo that is public.\n> \n> \n> I guess this is a standard cycle, right?\n> \n\nYou don't need to merge everything back into master or delete branches.\nWhen you 'git push', it only pushes remote tracking branches. (Branches that\nyou fetched from that repo).\nIf you do 'git push --all', it will push all your branches to the repo.\nIf you do 'git push REMOTE-REPO BRANCH', it will push just that branch. You\ncan, of course, list multiple branches.\n\n\nAsaf wrote:\n> \n> What I'm confused about is how to tag correctly versions that are stable,\n> Should I locally just add a tag and push the tag to the public repo?\n> \n\nYup.\n\n\nAsaf wrote:\n> \n> Is it enough to use a lightweight tagging for tagging a certain commit as\n> a release?\n> \n\nYes, but signing it makes others feel more confident, and if you at least\nannotate, you can provide some sort of description.\n\n\nAsaf wrote:\n> \n> Is it possible later on to checkout a tag, make a change and push the\n> change into the tagged version?\n> \n\nOnce again, yup, just do 'git checkout TAG'. Though you may want to do 'git\ncheckout -b NEW-BRANCH TAG'.\n\nGood luck,\nTim.\n-- \nView this message in context: http://www.nabble.com/Tagging-stable-releases-tp23045562p26093620.html\nSent from the git mailing list archive at Nabble.com.\n"}]}