[Python-Dev] IMPORTANT: 3.6 branch in Release Candidate stage, check-ins restricted!

[Ned Deily]

The tagging and manufacturing of 3.6.0 beta 4 is now underway and we are entering the Release Candidate stage.  From now until further notice, you should only push changes to 3.6 that meet the 3.6.0 release critical or final doc changes criteria described below.  All code changes pushed to 3.6 during this release candidate stage must be reviewed.  The restriction to only release-critical fixes will be lifted after the tagging of 3.6.0rc1 which is expected in about 2 weeks.  As usual, the actual v3.6.0b4 tag and other release-related updates will be pushed to the cpython repo once the release build process has been completed and tested.  This will be signaled by the 3.6.0b4 release availability email.

By the way: I have just noticed that I made an error in the cleanup steps following the previous beta, 3.6.0b3.  The patch level for post-b3 development builds was mistakenly set to 3.6.0b4+ instead of 3.6.0b3+.  (The release tarballs and installers are not affected.)  So don't be surprised when the patch level for post-b4 development builds remains 3.6.0b4+.  As far as I can anticipate that should not cause any problems.  My apologies!

--Ned

On Nov 21, 2016, at 05:35, Ned Deily <nad at python.org> wrote:
> The final beta snapshot planned for the 3.6 release cycle is scheduled to be tagged today within the next 12 hours.  We then begin the Release Candidate stage, the final days leading up to 3.6.0, with the release candidate scheduled to be tagged in about 2 weeks.  As I have noted previously, with the tagging today and release of beta 4, *all* non-critical bug fixes for 3.6.0 should now have been checked in.  From the b4 tag on, *only* release critical and doc fixes should be pushed for the release candidate.  A reminder from the Developer's Guide regarding the Release Candidate stage of the release cycle:
> 
> "A branch preparing for an RC release can only have bugfixes applied that have been reviewed by other core developers. Generally, these issues must be severe enough (e.g. crashes) that they deserve fixing before the final release. All other issues should be deferred to the next development cycle, since stability is the strongest concern at this point.  You cannot skip the peer review during an RC, no matter how small! Even if it is a simple copy-and-paste change, everything requires peer review from a core developer."
> 
> A goal for this release has been to have no changes between the release candidate and the final release other than the tag itself.  Remember that every time we make a change at this point, it puts a burden on and adds risk to our testing efforts and, more importantly, the efforts of our third-party package developers, downstream distributors, and end users helping us ensure that 3.6.0 will be a high-quality release.  I think everyone has been doing a great job so far in exercising good judgement about what is appropriate at each stage of our release cycle.  Thank you!  Now, after b4, unless a code change addresses a truly release critical issue, please target bug fixes for 3.6.1 and, of course, continue to target new features for 3.7.
> 
> This raises the issue of what process to follow for changes to the 3.6 branch following the b4 tag and up to the final 3.6.0 release.  During the last feature release cycle (3.5.0), we tried something a little bit different: having a 3.5 branch open during the beta phase and then using a special Bitbucket repo with pull requests for changes in the release candidate phase.  This was intended to ease the burden on us release managers trying to cherry pick a set of fixes into the RC and/or final releases while allowing the 3.5 branch to remain open to everyone for 3.5.1 changes.  My sense is that, while we all appreciated keeping the branch open for bug fixes, many of us were new to the Bitbucket PR process and found it more confusing than expected.  So for 3.6.0, I am trying to avoid going down that route.  But I do need your help.  First, throughout the release cycle I have tried to set expectations that the release candidate will be exactly what it says, a candidate for final release, and thus there should be at most a *very* small number of release critical fixes and final doc updates going in after b4 and with the goal of no changes after rc1.  Second, by keeping the rc phase changes to a minimum, I have also tried to keep the release candidate phase shorter so that we all can move on to focus on the next feature release and on  maintenance releases for 3.6 (schedules for both will be proposed soon).  Also, 3.6.0 is the last feature release cycle using our current development workflow.  Sometime after the 3.6.0 release, we will be phasing in our revised development workflow (thanks to Brett and crew!) and with it will come the opportunity for greater flexibility throughout the release cycle, with new tools like pull requests workflows and continuous integration testing.  So I don't think it makes sense to spend a lot of time tweaking our current process just for the final weeks of one release.
> 
> Therefore, what I am planning to do and asking you to do is:
> 
> 1. Sometime after 1800 UTC today when we are ready to start the 3.6.0b4 tagging and release manufacturing process, I will send an email announcement.
> 
> 2. Following that b4 tag notification and until rc1 is tagged on 2016-12-05 (in about two weeks), the 3.6 branch will *temporarily* be open only for fixes appropriate for 3.6.0, e.g. reviewed release critical items and final doc changes.  Don't forget to mark such items as "release blocker" in the bug tracker.
> 
> 3. Hold off pushing changes that are not 3.6.0 release critical until after rc1 is tagged.  You can continue to push bug fixes as appropriate to other open branches if you are willing to back port them to the 3.6 branch, as necessary, after rc1 is tagged.  Or, if you prefer to follow the normal development flow, take a bugfix holiday for the next two weeks and just hold off pushing any changes that affect 3.6.1 until after rc1 is tagged.  With those (hopefully) small inconveniences to you, we won't have to go through a special Bitbucket PR process and it will ensure that our 3.6 buildbots continue to test what's going into 3.6.0.
> 
> 4. Once rc1 is tagged, the 3.6 branch will again be open for the usual maintenance-release-appropriate changes destined for 3.6.1.  Any emergency fixes that might arise after rc1 and prior to 3.6.0 will be approved and merged from the 3.6 branch into the 3.6.0 release by me.  I'm really hoping we won't have to do that!
> 
> I hope that you find the process for the few remaining weeks leading up to the 3.6.0 release to not be too burdensome.  Please contact me if you have any questions about the 3.6.0 schedule or about whether a change is appropriate at this point in the 3.6.0 cycle.
> 
> To recap, the remaining milestones for 3.6.0:
> 
> 2016-11-21, ~1800 UTC: 3.6.0 beta 4 (important bug fixes and doc fixes)
> 
> 2016-11-21 to 2016-12-05: 3.6 branch open *only* for 3.6.0 release critical and doc fixes
> 
> 2016-12-05 (2 weeks from now) 3.6.0 release candidate 1 (3.6.0 code freeze, release critical bug fixes, doc fixes; 3.6 branch reopens for 3.6.1)
> 
> 2016-12-16 3.6.0 release (3.6.0rc1 plus any necessary emergency fixes)
> 
> Thank you all again for your efforts so far on 3.6.  Beethoven and I are looking forward to celebrating 3.6.0 on 12-16!
> 
> --Ned
> 
> http://cpython-devguide.readthedocs.io/en/latest/devcycle.html#release-candidate-rc
> 
> https://www.python.org/dev/peps/pep-0494/

--
  Ned Deily
  nad at python.org -- []