release branch naming scheme
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
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 <stadler@edirom.de> 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
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 <philomousos@gmail.com> 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 <stadler@edirom.de> 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
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 <ebbondar@gmail.com> 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 <philomousos@gmail.com> 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 <stadler@edirom.de> 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
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 <ebbondar@gmail.com> 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 <ebbondar@gmail.com> 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 <philomousos@gmail.com> 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 <stadler@edirom.de> 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
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 <ebbondar@gmail.com> 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 <philomousos@gmail.com> 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 <stadler@edirom.de> 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
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 <stadler@edirom.de> 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
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?)
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
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 <james.cummings@it.ox.ac.uk> 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
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 <philomousos@gmail.com>:
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 <james.cummings@it.ox.ac.uk> 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
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?!
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 <syd@paramedic.wwp.neu.edu>:
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
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 <syd@paramedic.wwp.neu.edu>:
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
participants (6)
-
Elisa -
Hugh Cayless -
James Cummings -
James Cummings
-
Peter Stadler -
Syd Bauman