release branch naming scheme

older
Reminder: Monthly telecon tomorrow

Peter Stadler

17 Mar 2016 17 Mar '16

2:06 p.m.

Is there any benefit in naming the release branches (both Guidelines and Stylesheets) „release-x.x.x“ rather than just „release“? If it was just „release“ we could have proper jenkins jobs for these branches [1] and wouldn’t need to update the config files for every release. (I guess we will be deleting those „release-x.x.x“ branches after the release but a „release“ branch could simply persist.) What do you think? Peter [1] along with documentation/archival at https://github.com/TEIC/TEI/tree/dev/Documents/Editing/Jenkins/jobs

Attachments:

signature.asc (application/pgp-signature — 455 bytes)

Show replies by date

Hugh Cayless

17 Mar 17 Mar

2:17 p.m.

New subject: [tei-council] release branch naming scheme

Shouldn't each release be a fresh branch off of dev though? If the release branch sticks around, don't we risk it diverging? That said, we could always name them "release" and nuke that branch when we're done with it. The Jenkins jobs will just not run if there isn't a branch with the right name, right? On Thu, Mar 17, 2016 at 9:06 AM, Peter Stadler wrote:

...

Is there any benefit in naming the release branches (both Guidelines and Stylesheets) „release-x.x.x“ rather than just „release“? If it was just „release“ we could have proper jenkins jobs for these branches [1] and wouldn’t need to update the config files for every release. (I guess we will be deleting those „release-x.x.x“ branches after the release but a „release“ branch could simply persist.)

What do you think? Peter

[1] along with documentation/archival at https://github.com/TEIC/TEI/tree/dev/Documents/Editing/Jenkins/jobs

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

Elisa

3:14 p.m.

New subject: [tei-council] release branch naming scheme

I think this was the very question Syd was raising earlier: Why do we bother with a temporary release branch , and why don't we simply merge changes directly into master from dev? Is there a special tie-in to Mr. Jenkins that necessitates the special, ephemeral "release" branch? Elisa Typeset by hand on my iPad

...

On Mar 17, 2016, at 9:17 AM, Hugh Cayless wrote:

Shouldn't each release be a fresh branch off of dev though? If the release branch sticks around, don't we risk it diverging? That said, we could always name them "release" and nuke that branch when we're done with it. The Jenkins jobs will just not run if there isn't a branch with the right name, right?

...
On Thu, Mar 17, 2016 at 9:06 AM, Peter Stadler wrote:

Is there any benefit in naming the release branches (both Guidelines and Stylesheets) „release-x.x.x“ rather than just „release“? If it was just „release“ we could have proper jenkins jobs for these branches [1] and wouldn’t need to update the config files for every release. (I guess we will be deleting those „release-x.x.x“ branches after the release but a „release“ branch could simply persist.)

What do you think? Peter

[1] along with documentation/archival at https://github.com/TEIC/TEI/tree/dev/Documents/Editing/Jenkins/jobs

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

Elisa

3:18 p.m.

New subject: [tei-council] release branch naming scheme

My own speculation about the necessity of the release branch is that its existence "freezes" a particular moment on dev that we all understand to be good and stable. Then, we hold it in release, double check it there over this two-week period, and also keep working as we do as usual on the dev branch...is that the idea? Elisa Typeset by hand on my iPad

...

On Mar 17, 2016, at 10:14 AM, Elisa wrote:

I think this was the very question Syd was raising earlier: Why do we bother with a temporary release branch , and why don't we simply merge changes directly into master from dev? Is there a special tie-in to Mr. Jenkins that necessitates the special, ephemeral "release" branch?

Elisa

Typeset by hand on my iPad

...
On Mar 17, 2016, at 9:17 AM, Hugh Cayless wrote:

Shouldn't each release be a fresh branch off of dev though? If the release branch sticks around, don't we risk it diverging? That said, we could always name them "release" and nuke that branch when we're done with it. The Jenkins jobs will just not run if there isn't a branch with the right name, right?

...
On Thu, Mar 17, 2016 at 9:06 AM, Peter Stadler wrote:

Is there any benefit in naming the release branches (both Guidelines and Stylesheets) „release-x.x.x“ rather than just „release“? If it was just „release“ we could have proper jenkins jobs for these branches [1] and wouldn’t need to update the config files for every release. (I guess we will be deleting those „release-x.x.x“ branches after the release but a „release“ branch could simply persist.)

What do you think? Peter

[1] along with documentation/archival at https://github.com/TEIC/TEI/tree/dev/Documents/Editing/Jenkins/jobs

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

Hugh Cayless

3:26 p.m.

New subject: [tei-council] release branch naming scheme

We want the release branch to start at a pretty good state on dev, yes, and then to get only updates that fix problems in the prose and/or fix something that we've decided is release-blocking. Meanwhile, work on dev can proceed as usual. Here's the basic idea as I understand it: branch | state --------------------------- dev | messy release | pretty stable master | very stable On Thu, Mar 17, 2016 at 10:18 AM, Elisa wrote:

...

My own speculation about the necessity of the release branch is that its existence "freezes" a particular moment on dev that we all understand to be good and stable. Then, we hold it in release, double check it there over this two-week period, and also keep working as we do as usual on the dev branch...is that the idea?

Elisa Typeset by hand on my iPad

...
On Mar 17, 2016, at 10:14 AM, Elisa wrote:

I think this was the very question Syd was raising earlier: Why do we bother with a temporary release branch , and why don't we simply merge changes directly into master from dev? Is there a special tie-in to Mr. Jenkins that necessitates the special, ephemeral "release" branch?

Elisa

Typeset by hand on my iPad

...
On Mar 17, 2016, at 9:17 AM, Hugh Cayless wrote:

Shouldn't each release be a fresh branch off of dev though? If the release branch sticks around, don't we risk it diverging? That said, we could always name them "release" and nuke that branch when we're done with it. The Jenkins jobs will just not run if there isn't a branch with the right name, right?

...
On Thu, Mar 17, 2016 at 9:06 AM, Peter Stadler wrote:

Is there any benefit in naming the release branches (both Guidelines and Stylesheets) „release-x.x.x“ rather than just „release“? If it was just „release“ we could have proper jenkins jobs for these branches [1] and wouldn’t need to update the config files for every release. (I guess we will be deleting those „release-x.x.x“ branches after the release but a „release“ branch could simply persist.)

What do you think? Peter

[1] along with documentation/archival at https://github.com/TEIC/TEI/tree/dev/Documents/Editing/Jenkins/jobs

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

Hugh Cayless

3:19 p.m.

New subject: [tei-council] release branch naming scheme

We don't use master because, as Peter said, we want master to have only stable versions in it. So if you use the master branch, you'll never encounter anything but a release in there. Release branches are more stable than dev, but not completely so. On Thu, Mar 17, 2016 at 10:14 AM, Elisa wrote:

...

I think this was the very question Syd was raising earlier: Why do we bother with a temporary release branch , and why don't we simply merge changes directly into master from dev? Is there a special tie-in to Mr. Jenkins that necessitates the special, ephemeral "release" branch?

Elisa

Typeset by hand on my iPad

...
On Mar 17, 2016, at 9:17 AM, Hugh Cayless wrote:

Shouldn't each release be a fresh branch off of dev though? If the release branch sticks around, don't we risk it diverging? That said, we could always name them "release" and nuke that branch when we're done with it. The Jenkins jobs will just not run if there isn't a branch with the right name, right?

...
On Thu, Mar 17, 2016 at 9:06 AM, Peter Stadler wrote:

Is there any benefit in naming the release branches (both Guidelines and Stylesheets) „release-x.x.x“ rather than just „release“? If it was just „release“ we could have proper jenkins jobs for these branches [1] and wouldn’t need to update the config files for every release. (I guess we will be deleting those „release-x.x.x“ branches after the release but a „release“ branch could simply persist.)

What do you think? Peter

[1] along with documentation/archival at https://github.com/TEIC/TEI/tree/dev/Documents/Editing/Jenkins/jobs

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

Hugh Cayless

3:29 p.m.

New subject: [tei-council] release branch naming scheme

I guess the other benefit to labeled release branches is if we might want them to stick around for a while. I dunno if there's a need for that... On Thu, Mar 17, 2016 at 9:06 AM, Peter Stadler wrote:

...

Is there any benefit in naming the release branches (both Guidelines and Stylesheets) „release-x.x.x“ rather than just „release“? If it was just „release“ we could have proper jenkins jobs for these branches [1] and wouldn’t need to update the config files for every release. (I guess we will be deleting those „release-x.x.x“ branches after the release but a „release“ branch could simply persist.)

What do you think? Peter

[1] along with documentation/archival at https://github.com/TEIC/TEI/tree/dev/Documents/Editing/Jenkins/jobs

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

Syd Bauman

7:19 p.m.

New subject: [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?)

James Cummings

9:01 p.m.

New subject: [tei-council] release branch naming scheme

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

Hugh Cayless

9:26 p.m.

New subject: [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

Peter Stadler

18 Mar 18 Mar

10:04 a.m.

New subject: [tei-council] release branch naming scheme

Ok with me to stick with "release-#.#.#“. It’s not that much work for the Jenkins maintainers but maybe we should appoint only one for a release? I don’t think there’s a need for having every Jenkins build this temporary branch?! Best Peter

...

Am 17.03.2016 um 21:26 schrieb Hugh Cayless :

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

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

Syd Bauman

24 Mar 24 Mar

5:45 p.m.

New subject: [tei-council] release branch naming scheme

Peter -- I'm not sure I understand why we would want mutliple Jenkins building in general, but then not right at release time when it seems most important that we have fast, stable capability to build.

...

Ok with me to stick with "release-#.#.#“. It’s not that much work for the Jenkins maintainers but maybe we should appoint only one for a release? I don’t think there’s a need for having every Jenkins build this temporary branch?!

Peter Stadler

31 Mar 31 Mar

10:22 a.m.

New subject: [tei-council] release branch naming scheme

Maybe we will talk about that issue during the conf call but my thoughts are simply: * Master and dev branch are no issue. These should be standard jobs on every Jenkins and the job descriptions can easily be documented in our repo. * Due to our naming scheme "release-#.#.#“ for the release branch (and since we do not know in advance what the next release number will be exactly) it needs manual configuration of this job on every Jenkins for every release. Since this is only a temporary branch (and job) I thought it would be sufficient to have this on one dedicated Jenkins (appointed per release). Best Peter

...

Am 24.03.2016 um 17:45 schrieb Syd Bauman :

Peter -- I'm not sure I understand why we would want mutliple Jenkins building in general, but then not right at release time when it seems most important that we have fast, stable capability to build.

...
Ok with me to stick with "release-#.#.#“. It’s not that much work for the Jenkins maintainers but maybe we should appoint only one for a release? I don’t think there’s a need for having every Jenkins build this temporary branch?! -- 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

James Cummings

12:27 p.m.

New subject: [tei-council] release branch naming scheme

I agree. I had not set up the standard jobs for Master/Dev distinction on the Oxford Jenkins but am willing to do so, to also have the release-#.#.# seems unnecessary. The reason we have multiple Jenkins is in case one of them goes down for some protracted time... not for extra confusion during release. -James On 31/03/16 09:22, Peter Stadler wrote:

...

Maybe we will talk about that issue during the conf call but my thoughts are simply: * Master and dev branch are no issue. These should be standard jobs on every Jenkins and the job descriptions can easily be documented in our repo. * Due to our naming scheme "release-#.#.#“ for the release branch (and since we do not know in advance what the next release number will be exactly) it needs manual configuration of this job on every Jenkins for every release. Since this is only a temporary branch (and job) I thought it would be sufficient to have this on one dedicated Jenkins (appointed per release).

Best Peter

...
Am 24.03.2016 um 17:45 schrieb Syd Bauman :

Peter -- I'm not sure I understand why we would want mutliple Jenkins building in general, but then not right at release time when it seems most important that we have fast, stable capability to build.

...
Ok with me to stick with "release-#.#.#“. It’s not that much work for the Jenkins maintainers but maybe we should appoint only one for a release? I don’t think there’s a need for having every Jenkins build this temporary branch?! -- 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

-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

3150

Age (days ago)

3164

Last active (days ago)

List overview

Download

13 comments

6 participants

participants (6)

Elisa
Hugh Cayless
James Cummings
James Cummings
Peter Stadler
Syd Bauman