{"thread":{"id":"43094","subject":"Re: GIT - releases workflow","startedAt":"2006-12-12T22:44:23Z","lastAt":"2006-12-13T13:13:47Z","messageCount":10,"participants":["Shawn Pearce","Sean Kelley","Johannes Schindelin","Linus Torvalds","Andreas Ericsson","Matthias Kestenholz"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"296904","messageId":"89b129c60612121444t18ba94ecv57eea4c72be1663a@mail.gmail.com","threadId":"43094","inReplyTo":null,"subject":"GIT - releases workflow","fromName":"Sean Kelley","fromEmail":"sean.v.kelley@gmail.com","sentAt":"2006-12-12T22:44:23Z","receivedAt":"2006-12-12T22:44:23Z","isPatch":false,"sender":{"key":"sean.v.kelley@gmail.com","avatar":null},"body":"I was wondering if anyone could share ideas on how best to use GIT to\nhandle releases for those working with a remote GIT repository? Do\nyou create a branch and push it to the remote? Thus you have a new\nbranch referencing the particular release?\n\nSean\n\n-- \n"},{"id":"296844","messageId":"Pine.LNX.4.63.0612122353320.2807@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43094","inReplyTo":"89b129c60612121444t18ba94ecv57eea4c72be1663a@mail.gmail.com","subject":"Re: GIT - releases workflow","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-12T22:54:14Z","receivedAt":"2006-12-12T22:54:14Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 12 Dec 2006, Sean Kelley wrote:\n\n> I was wondering if anyone could share ideas on how best to use GIT to \n> handle releases for those working with a remote GIT repository? Do you \n> create a branch and push it to the remote? Thus you have a new branch \n> referencing the particular release?\n\nWhy not just tag the release, and push the tag?\n\nHth,\nDscho\n"},{"id":"295732","messageId":"Pine.LNX.4.64.0612121831570.3535@woody.osdl.org","threadId":"43094","inReplyTo":"89b129c60612121444t18ba94ecv57eea4c72be1663a@mail.gmail.com","subject":"Re: GIT - releases workflow","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-13T02:43:08Z","receivedAt":"2006-12-13T02:43:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 12 Dec 2006, Sean Kelley wrote:\n>\n> I was wondering if anyone could share ideas on how best to use GIT to\n> handle releases for those working with a remote GIT repository? Do\n> you create a branch and push it to the remote? Thus you have a new\n> branch referencing the particular release?\n\nI don't think there is a \"right\" model, but at least _one_ model is what \nthe kernel uses:\n - the actual \"release\" is just tagged\n - any release development (ie \"maintenance\") is literally done in a \n totally separate repository, both from a development standpoint _and_ \n an actual release management standpoint.\n\nThis may sound strange, but it actually has what I consider to be huge \nadvantages:\n\n - it fits very well in the \"distributed\" mental model\n\n - it makes the separation of \"maintenance\" and \"development\" very very \n clear. It's clear at all levels that the two are not the same thing, \n don't have the same goals, and often not done by even the same groups, \n or even by same management.\n\nI think the second point is actually important.\n\nAt the same time, the distributed model of git means that if you want to \nmix the two trees, you easily can: you just fetch from the two independent \nrelease trees into the same repository. So the fact that they are \nmaintained completely independently doesn't mean that they can't be \njoined, it just means that there's a clear separation at all levels.\n\nAlso note how _different_ releases may well end up having _separate_ \nrepositories. So it's not that there is \"one repository for development, \nand one repository for maintenance\". It's literally \"one repository for \n_each_ release maintenance\".\n\nNow, I think this kind of \"separate repository for release maintenance \ntrees\" is actually a great model, and I think it can make perfect sense in \nvarious commercial/proprietary settings too (ie I know from experience \nthat you tend to often have separate groups and very different rules for \nmaintenance, so having the separate repository really does make sense).\n\nBut at the same time, for a smaller project, it obviously does NOT make \nsense. Git itself, for example, just has a \"maint\" branch, and does \neverything with the same maintainer, and in the same repository. Within \nsomething like git, that makes sense, because there just isn't a separate \n\"stable tree maintainer\", and trying to enforce that kind of thing would \njust be insane anyway within the setting of git.\n\nSo in some settings, you might just have a branch for each stable release, \nor as in the case of git, just a single branch for \"maintenance\", just \nbecause nobody is going to maintain older releases really at all (that \nmight change with time, of course, but I think it's a pretty common \npattern for smaller projects).\n\nIn short: I don't think there is \"one correct way\" to do these things.\n\n"},{"id":"297943","messageId":"1166001019.19098.4.camel@localhost.localdomain","threadId":"43094","inReplyTo":"Pine.LNX.4.63.0612122353320.2807@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: GIT - releases workflow","fromName":"Matthias Kestenholz","fromEmail":"lists@spinlock.ch","sentAt":"2006-12-13T09:10:19Z","receivedAt":"2006-12-13T09:10:19Z","isPatch":false,"sender":{"key":"lists@spinlock.ch","avatar":null},"body":"Hi,\n\nOn Tue, 2006-12-12 at 23:54 +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 12 Dec 2006, Sean Kelley wrote:\n> \n> > I was wondering if anyone could share ideas on how best to use GIT to \n> > handle releases for those working with a remote GIT repository? Do you \n> > create a branch and push it to the remote? Thus you have a new branch \n> > referencing the particular release?\n> \n> Why not just tag the release, and push the tag?\n\nI am doing both in my web SDK project.\n\nI currently have two branches, master and maint/v1. Over time, if\nnecessary, I'll open new branches named maint/v2, maint/v3 etc.\n\nNew development happens on master, bugfixes go to maint/v1 and get\nmerged into master. If I do bugfix releases (2.0.x), I tag the tip of\nthe maint/v1 branch.\n\nI need a full branch, because I need the ability to do bugfixes for the\nalready-released version.\n\nMatthias\n"},{"id":"295660","messageId":"Pine.LNX.4.63.0612131133160.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43094","inReplyTo":"1166001019.19098.4.camel@localhost.localdomain","subject":"Re: GIT - releases workflow","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-13T10:36:11Z","receivedAt":"2006-12-13T10:36:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 13 Dec 2006, Matthias Kestenholz wrote:\n\n> On Tue, 2006-12-12 at 23:54 +0100, Johannes Schindelin wrote:\n> > \n> > On Tue, 12 Dec 2006, Sean Kelley wrote:\n> > \n> > > I was wondering if anyone could share ideas on how best to use GIT to \n> > > handle releases for those working with a remote GIT repository? Do you \n> > > create a branch and push it to the remote? Thus you have a new branch \n> > > referencing the particular release?\n> > \n> > Why not just tag the release, and push the tag?\n> \n> I am doing both in my web SDK project.\n> \n> I currently have two branches, master and maint/v1. Over time, if\n> necessary, I'll open new branches named maint/v2, maint/v3 etc.\n> \n> New development happens on master, bugfixes go to maint/v1 and get\n> merged into master. If I do bugfix releases (2.0.x), I tag the tip of\n> the maint/v1 branch.\n> \n> I need a full branch, because I need the ability to do bugfixes for the\n> already-released version.\n\nAh, that's right. I always forget that there are maintenance releases \n(mostly in Cathedral-ish projects)... I am not a release engineer during \nmy day job, and I am just as happy about that.\n\nBTW, if the maintenance releases are sparse and long between, you can \nactually create the branch from the tag, fix, and tag with the new version \nnumber. No need to start the branches early.\n\nCiao,\nDscho\n"},{"id":"298096","messageId":"20061213105614.GB9484@spearce.org","threadId":"43094","inReplyTo":"Pine.LNX.4.63.0612131133160.3635@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: GIT - releases workflow","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-13T10:56:14Z","receivedAt":"2006-12-13T10:56:14Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> > > On Tue, 12 Dec 2006, Sean Kelley wrote:\n> > > \n> > > > I was wondering if anyone could share ideas on how best to use GIT to \n> > > > handle releases for those working with a remote GIT repository? Do you \n> > > > create a branch and push it to the remote? Thus you have a new branch \n> > > > referencing the particular release?\n> \n> BTW, if the maintenance releases are sparse and long between, you can \n> actually create the branch from the tag, fix, and tag with the new version \n> number. No need to start the branches early.\n\nIndeed.\n\nI actually have a fancy (==~800 poorly written lines) Perl script that:\n\n * Creates a \"build\" git repository using objects/info/alternates.\n The user can reuse an existing directory if they have one.\n (Obviously reusing an existing directory is faster, less files\n to setup in the working directory.)\n\n * Offers the user a menu of top 10 most recent tags to choose as\n a base version. Tags are displayed first sorted by which tag\n is considered to be in which runtime environment (QA testing,\n end user testing, production release), then by tag date for\n those tags not in any specific environment.\n\n * Offers the user a menu of branches in a pre-configured namespace\n (e.g. refs/heads/ready) which have commits not yet merged into\n the selected base. Users can attempt to pull as many branches\n as they like, the script merges each in turn until none remain\n or the user says \"build!\".\n\n * Increments the last component of the 'version number' of the tag\n and makes an annotated tag object in the local build repository.\n\n * Runs the project's configured build command (from repo-config\n taken from builder.command variable).\n\n * If builder.command is successful pushes the tag back to the origin\n repository; if builder.command fails pushes the HEAD revision\n up as a branch (e.g. refs/heads/failed/foo) so that someone more\n skilled in the art of failed builds can look into the matter.\n\nThe script is really meant for QA people to take in topic branches\nfrom developers and apply them to a specific version, test that new\nversion, then ship that new version. Some of the QA people I work\nwith aren't developers and have a somewhat difficult time making\na build from source; this script makes it a pretty simple process.\n\nThe version number incrementor is smart; its based off commit\nlineage. It can automatically create a \"2.0.1\" tag when \"2.1\"\nhas already been made but \"2.0.1\" is a bugfix of \"2\" or \"2.0\".\n\nI should clean it up some and post it, just in case others may\nbe interested. I'll try to do that this weekend.\n\n-- \n"},{"id":"293837","messageId":"20061213111450.GB31177@spearce.org","threadId":"43094","inReplyTo":"20061213105614.GB9484@spearce.org","subject":"Re: GIT - releases workflow","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-13T11:14:50Z","receivedAt":"2006-12-13T11:14:50Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Shawn Pearce wrote:\n> Johannes Schindelin wrote:\n> > > > On Tue, 12 Dec 2006, Sean Kelley wrote:\n> > > > \n> > > > > I was wondering if anyone could share ideas on how best to use GIT to \n> > > > > handle releases for those working with a remote GIT repository? Do you \n> > > > > create a branch and push it to the remote? Thus you have a new branch \n> > > > > referencing the particular release?\n> > \n> > BTW, if the maintenance releases are sparse and long between, you can \n> > actually create the branch from the tag, fix, and tag with the new version \n> > number. No need to start the branches early.\n> \n> Indeed.\n[snip]\n> The script is really meant for QA people to take in topic branches\n> from developers and apply them to a specific version, test that new\n> version, then ship that new version. Some of the QA people I work\n> with aren't developers and have a somewhat difficult time making\n> a build from source; this script makes it a pretty simple process.\n> \n> The version number incrementor is smart; its based off commit\n> lineage. It can automatically create a \"2.0.1\" tag when \"2.1\"\n> has already been made but \"2.0.1\" is a bugfix of \"2\" or \"2.0\".\n\nWhat I really should have said was the general idea here is that\nwe never even have a trunk.\n\nDevelopers work on topic branches and share/merge those individual\nbranches as necessary to evolve a topic. When its suitably cooked\nin developer land it gets sent off to testing by being pushed into\na someewhat descriptive ref under refs/heads/ready.\n\nTesting can then accept topics by merging them together and creating\ntags via the described script.\n\nDevelopers update their still cooking topic branches when necessary\nby pulling in the tags. git merge is smart enough to dereference the\ntag and generate the merge. Normally this is held off to the latest\npossible moment, and only to make sure there aren't any unexpected\nsurprises from the merge waiting for the unsuspecting QA person.\n\nDevelopers start new topic branches off the relevent tag they need\nto work on. New features are often made off the latest tag from QA;\nbug fixes are often off the tag currently in production.\n\nSo like I said, we're basically trunkless and happy. Tag happy.\nThank you Linus, et.al. for packed refs!\n\n-- \n"},{"id":"295182","messageId":"89b129c60612130434q18c69c7bxd96b7db0c423d8ea@mail.gmail.com","threadId":"43094","inReplyTo":"1166001019.19098.4.camel@localhost.localdomain","subject":"Re: GIT - releases workflow","fromName":"Sean Kelley","fromEmail":"sean.v.kelley@gmail.com","sentAt":"2006-12-13T12:34:04Z","receivedAt":"2006-12-13T12:34:04Z","isPatch":false,"sender":{"key":"sean.v.kelley@gmail.com","avatar":null},"body":"Hi,\n\nOn 12/13/06, Matthias Kestenholz wrote:\n> Hi,\n>\n> On Tue, 2006-12-12 at 23:54 +0100, Johannes Schindelin wrote:\n> > Hi,\n> >\n> > On Tue, 12 Dec 2006, Sean Kelley wrote:\n> >\n> > > I was wondering if anyone could share ideas on how best to use GIT to\n> > > handle releases for those working with a remote GIT repository? Do you\n> > > create a branch and push it to the remote? Thus you have a new branch\n> > > referencing the particular release?\n> >\n> > Why not just tag the release, and push the tag?\n>\n> I am doing both in my web SDK project.\n>\n> I currently have two branches, master and maint/v1. Over time, if\n> necessary, I'll open new branches named maint/v2, maint/v3 etc.\n>\n> New development happens on master, bugfixes go to maint/v1 and get\n> merged into master. If I do bugfix releases (2.0.x), I tag the tip of\n> the maint/v1 branch.\n\n\nThat seems to match my use case. So if I follow your description:\n\n git checkout -b maint/v0.1\n git pull . \n git push origin maint/v0.1:maint/v0.1\n\nNow the initial branch release is on the remote repo. So that my team\ncan start hacking on the release branch. When we are ready, we need\nto create a release tag.\n\n git tag -a -m \"Release 0.1.0\" rel-v0.1.0\n\nHow do I push that tag that I created to the maint/v0.1 branch on the\nremote repository?\n\nThanks,\n\nSean\n\n\n>\n> I need a full branch, because I need the ability to do bugfixes for the\n> already-released version.\n>\n> Matthias\n>\n>\n\n\n-- \n"},{"id":"294201","messageId":"89b129c60612130439m452b315x2278456396a248a5@mail.gmail.com","threadId":"43094","inReplyTo":"89b129c60612130434q18c69c7bxd96b7db0c423d8ea@mail.gmail.com","subject":"Re: GIT - releases workflow","fromName":"Sean Kelley","fromEmail":"sean.v.kelley@gmail.com","sentAt":"2006-12-13T12:39:22Z","receivedAt":"2006-12-13T12:39:22Z","isPatch":false,"sender":{"key":"sean.v.kelley@gmail.com","avatar":null},"body":"Hi,\n\nOn 12/13/06, Sean Kelley wrote:\n> Hi,\n>\n> On 12/13/06, Matthias Kestenholz wrote:\n> >\n> How do I push that tag that I created to the maint/v0.1 branch on the\n> remote repository?\n\nNever mind, I answered my own question. Sorry for asking without\ndoing my research first.\n\n git push --tags origin\n\nThanks,\n\nSean\n>\n> Thanks,\n>\n> Sean\n>\n>\n> >\n> > I need a full branch, because I need the ability to do bugfixes for the\n> > already-released version.\n> >\n> > Matthias\n> >\n> >\n>\n>\n> --\n> Sean Kelley\n>\n\n\n-- \n"},{"id":"296916","messageId":"457FFC8B.5010501@op5.se","threadId":"43094","inReplyTo":"89b129c60612130439m452b315x2278456396a248a5@mail.gmail.com","subject":"Re: GIT - releases workflow","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-12-13T13:13:47Z","receivedAt":"2006-12-13T13:13:47Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Sean Kelley wrote:\n> Hi,\n> \n> On 12/13/06, Sean Kelley wrote:\n>> Hi,\n>>\n>> On 12/13/06, Matthias Kestenholz wrote:\n>> >\n>> How do I push that tag that I created to the maint/v0.1 branch on the\n>> remote repository?\n> \n> Never mind, I answered my own question. Sorry for asking without\n> doing my research first.\n> \n> git push --tags origin\n> \n\nSort of, but not quite. This will push *all* your tags to wherever \norigin points to. If you, like me, use un-annotated tags to remember a \nparticular snapshot you will then push a number of tags named \"foo\", \n\"fnurg\", \"sdf\" and \"werwer\" to the mothership repo.\n\n\tgit push origin v0.1\n\nworks marvellously though.\n\nBtw, this behaviour of mine, coupled with the company policy of only \nallowing annotated tags signed by the project maintainer as \nrelease-tags, lead to the creation of the update-hook I believe is still \nshipped as the default update-hook template with the git repo. It \ndisallows un-annotated tags completely and should be used on the \nmothership repo.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"}]}