Re: [tei-council] release branch naming scheme

Basically any state that wasn’t part of a deleted branch should stick around forever (commits in deleted branches are subject to being pruned). I can see pros and cons, and they’re mostly social rather than technical. "release" is a bit easier to deal with on Jenkins. The maintainers don’t need to do anything special: they can just create a build of the "release" branch and leave it set up indefinitely. "release-#.#.#" does what it says on the tin. It’s immediately obvious what it is, and we don’t have to worry about folks having stale release branches hanging around. I’m not sure if there are any potential bad consequences there though…I suppose Council members could get into the nasty merge scenarios we see sometimes when we have branches we don’t keep current with dev. Git Flow recommends the "release-#.#.#" naming scheme, but that might be for the scenario where you have more than one release branch going at the same time, which I don’t think we’re likely to face unless we end up, e.g., supporting P5 and P6 concurrently. On balance, I think maybe the downsides to "release" outweigh those of "release-#.#.#" a bit, but I’m not a Jenkins maintainer, so it doesn’t mean any extra work for me :-)

On Mar 17, 2016, at 16:01 , James Cummings wrote:

If a release branch is actually released via master then we can always get that release via the Vault or as previous merges on Master, right? Why would someone want to check out a particular release that wasn't a stage in dev or master?

Maybe I'm not understanding. James

-- Dr James Cummings, Academic IT, University of Oxford

-----Original Message----- From: Syd Bauman [syd@paramedic.wwp.neu.edu] Received: Thursday, 17 Mar 2016, 18:19 To: tei-council@lists.tei-c.org [tei-council@lists.tei-c.org] Subject: Re: [tei-council] release branch naming scheme

I think either a) release branches get named "release", and die shortly after they have been merged into "master" b) release branches get named "release-X.Y.Z", and survive until someone decides otherwise.

Seems to me (a) is easier on the Jenkins end of the world. And while (b) may be slightly easier if one ever wants to go back and checkout a particular release, I bet the Jenkins bit outweighs the convenience of a named branch to go back to. (After all, git is a revision control system, it's got to be easy to say "checkout the master branch is it was on DATE", no?) -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived