Git branch handling leading up to 2.0 release and the end of the Jenkins 1.x line
56 views
Skip to first unread message
Daniel Beck
Mar 23, 2016, 6:07:49 PM3/23/16
to Jenkins Developers, Kohsuke Kawaguchi
Hi everyone,
The following is my current plan and proposal how to handle the '2.0' and 'master' branches leading up to 2.0 release. Please respond if I overlooked something. You can find the current 2.0 release schedule here:
https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+2.0#Jenkins2.0-RoughTimeline
March 23:
We're aiming for the 2.0 beta release from the '2.0' branch later today. 'master' has been merged into '2.0' earlier today.
---
March 27(ish): Release of Jenkins 1.655 from 'master'. This will be the last release of the 1.x line (see March 30).
---
March 30:
In one week, 'master' will again be merged into '2.0'. This will be released as 2.0 RC from the '2.0' branch. Ideally we're not going to merge crazy stuff into 'master' between now and next Wednesday to keep the risk of the 2.0 RC being terrible low.
Any unmerged pull requests against '2.0' will be closed, and '2.0' will be merged into 'master'. This means that from that point on, anything happening on the 'master' branch will be released as 2.1, as it makes no sense to continue releasing 1.x weeklies while 2.0 code is frozen and we're preparing the release.
Pull requests targeting 2.1 and beyond should be opened against 'master'.
---
April 3:
This weekly release will be skipped.
---
April 6:
Release 2.0 from the '2.0' branch (unless a critical bug is found in RC, of course). Merge '2.0' into 'master'.
---
April 10(ish):
Release 2.1 from the 'master' branch.
The following is my current plan and proposal how to handle the '2.0' and 'master' branches leading up to 2.0 release. Please respond if I overlooked something. You can find the current 2.0 release schedule here:
https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+2.0#Jenkins2.0-RoughTimeline
March 23:
We're aiming for the 2.0 beta release from the '2.0' branch later today. 'master' has been merged into '2.0' earlier today.
---
March 27(ish): Release of Jenkins 1.655 from 'master'. This will be the last release of the 1.x line (see March 30).
---
March 30:
In one week, 'master' will again be merged into '2.0'. This will be released as 2.0 RC from the '2.0' branch. Ideally we're not going to merge crazy stuff into 'master' between now and next Wednesday to keep the risk of the 2.0 RC being terrible low.
Any unmerged pull requests against '2.0' will be closed, and '2.0' will be merged into 'master'. This means that from that point on, anything happening on the 'master' branch will be released as 2.1, as it makes no sense to continue releasing 1.x weeklies while 2.0 code is frozen and we're preparing the release.
Pull requests targeting 2.1 and beyond should be opened against 'master'.
---
April 3:
This weekly release will be skipped.
---
April 6:
Release 2.0 from the '2.0' branch (unless a critical bug is found in RC, of course). Merge '2.0' into 'master'.
---
April 10(ish):
Release 2.1 from the 'master' branch.
James Nord
Mar 24, 2016, 11:32:27 AM3/24/16
to Jenkins Developers, k...@kohsuke.org, m...@beckweb.net
So where do fixes to the 2.0 go? Master and cherry-picked or 2.0 and merged down.
I'm not sure why this is being treated differently from an LTS - which I would guess 2.0 would be - otherwise why does it need stabilization - it's similar yet different... If it's not a LTS version (as the next LTS version has been choses and it wasn' t 2.0 why is this extra needed - how is this different from weeklies?) Is this a new process going forward etc etc...
IIRC it was also stated that there was going to be a code review of 2.0 before - I guess this is the initial merge 2.0 branch to master - is that no longer planned/ being swept under the carpet? - otherwise I would have probably been a lot more diligent / rigorous on code reviewing all the changes going in.
Daniel Beck
Mar 24, 2016, 12:59:47 PM3/24/16
to James Nord, Jenkins Developers, k...@kohsuke.org
If they are intended to make it into 2.0, the '2.0' branch. If they are intended for 2.1, 'master' from next Wednesday on. (Or maybe build on top of 2.0, file against master now, and link to the 'real' diff without all of 2.0 in the PR description.)
> I'm not sure why this is being treated differently from an LTS - which I would guess 2.0 would be - otherwise why does it need stabilization - it's similar yet different... If it's not a LTS version (as the next LTS version has been choses and it wasn' t 2.0 why is this extra needed - how is this different from weeklies?)
Because there's a whole bunch of unusually large changes and a lot of attention on the final version. So I'd prefer we don't mess this up.
> Is this a new process going forward
No. We're going back to regular weeklies after the 2.0 release. (And I really hope this is the last release like this for a long time, another 11 years would be fine with me.)
It will also not disrupt the LTS schedule: We're scheduled to choose a baseline in July. It is very likely to be a 2.x, but that's just because by then the releases of the previous ~10 weeks will have been 2.x.
> IIRC it was also stated that there was going to be a code review of 2.0 before - I guess this is the initial merge 2.0 branch to master - is that no longer planned/ being swept under the carpet?
I don't see how this is remotely practical given the scope of changes that went into the 2.0 branch. So if you held off reviewing things and filing issues until now, please do so now.
> - otherwise I would have probably been a lot more diligent / rigorous on code reviewing all the changes going in.
There are some known issues with some of the changes in the 2.0 branch that need to be fixed before 2.0 RC. Those have been filed in Jira. But other than that, everyone had plenty of time to comment on the the PRs.
> I'm not sure why this is being treated differently from an LTS - which I would guess 2.0 would be - otherwise why does it need stabilization - it's similar yet different... If it's not a LTS version (as the next LTS version has been choses and it wasn' t 2.0 why is this extra needed - how is this different from weeklies?)
> Is this a new process going forward
It will also not disrupt the LTS schedule: We're scheduled to choose a baseline in July. It is very likely to be a 2.x, but that's just because by then the releases of the previous ~10 weeks will have been 2.x.
> IIRC it was also stated that there was going to be a code review of 2.0 before - I guess this is the initial merge 2.0 branch to master - is that no longer planned/ being swept under the carpet?
> - otherwise I would have probably been a lot more diligent / rigorous on code reviewing all the changes going in.
Reply all
Reply to author
Forward
0 new messages