[Python-Dev] IMPORTANT: 3.6.0b4 snapshot today, workflow changes for the final weeks of 3.6.0
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 con
Re: [Python-Dev] [Python-checkins] Daily reference leaks (b78574cb00ab): sum=1120
On 2016-11-19 2:46 PM, Kevin Modzelewski wrote: Hi Yury, you may be interested in some leak-finding code that wrote for Pyston. It uses the GC infrastructure to show you objects that were directly leaked, ignoring indirect leaks -- ie objects that were only leaked because they were referenced by a leaked object. It can often give you a very small list of objects to look into (depending on how many non-gc objects were leaked). If you're interested I can try porting it to CPython. https://github.com/dropbox/pyston/blob/master/from_cpython/Modules/gcmodule.c#L894 Hi Kevin, Nice work! Anything to help to find refleaks is welcome, it's really a painful process sometimes. As for porting it to CPython - I don't see why not. We can add this new API to debug builds only, at least in the beginning. Thank you! Yury ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] IMPORTANT: 3.6 branch in Release Candidate stage, check-ins restricted!
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 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 relea se, 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 workf
[Python-Dev] [RELEASE] Python 3.6.0b4 is now available
On behalf of the Python development community and the Python 3.6 release team, I'm pleased to announce the availability of Python 3.6.0b4. 3.6.0b4 is the last planned beta release of Python 3.6, the next major release of Python. Among the new major new features in Python 3.6 are: * PEP 468 - Preserving the order of **kwargs in a function * PEP 487 - Simpler customization of class creation * PEP 495 - Local Time Disambiguation * PEP 498 - Literal String Formatting * PEP 506 - Adding A Secrets Module To The Standard Library * PEP 509 - Add a private version to dict * PEP 515 - Underscores in Numeric Literals * PEP 519 - Adding a file system path protocol * PEP 520 - Preserving Class Attribute Definition Order * PEP 523 - Adding a frame evaluation API to CPython * PEP 524 - Make os.urandom() blocking on Linux (during system startup) * PEP 525 - Asynchronous Generators (provisional) * PEP 526 - Syntax for Variable Annotations (provisional) * PEP 528 - Change Windows console encoding to UTF-8 * PEP 529 - Change Windows filesystem encoding to UTF-8 * PEP 530 - Asynchronous Comprehensions Please see "What’s New In Python 3.6" for more information: https://docs.python.org/3.6/whatsnew/3.6.html You can find Python 3.6.0b4 here: https://www.python.org/downloads/release/python-360b4/ Beta releases are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage maintainers of third-party Python projects to test with 3.6 during the beta phase and report issues found to bugs.python.org as soon as possible. While the release is feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (2016-12-05). Our goal is have no changes after rc1. To achieve that, it will be extremely important to get as much exposure for 3.6 as possible during the beta phase. Please keep in mind that this is a preview release and its use is not recommended for production environments The next pre-release of Python 3.6 will be 3.6.0rc1, the release candidate, currently scheduled for 2016-12-05. The official release of Python 3.6.0 is currently scheduled for 2016-12-16. More information about the release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ -- Ned Deily [email protected] -- [] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 3.6 branch now open only for 3.6.0 release critical fixes and doc updates!
On Nov 22, 2016, at 02:02, Ned Deily wrote: > On behalf of the Python development community and the Python 3.6 release > team, I'm pleased to announce the availability of Python 3.6.0b4. 3.6.0b4 > is the last planned beta release of Python 3.6, the next major release of > Python. [...] OK, all of the release engineering for 3.6.0b4 is complete. The 3.6 branch in the cpython repo is now available again but, as noted, *only* for reviewed release critical fixes appropriate for the 3.6.0 final and for final 3.6.0 doc updates! Again, until 3.6.0rc1 is tagged, scheduled to happen in two weeks on 2016-12-05, please do *not* push non release-critical code of any kind to the 3.6 branch; after rc1 is tagged, the 3.6 branch will be open for 3.6.1 changes. Please use these two weeks to thoroughly review and, as necessary, update the What's New In Python 3.6 document (thanks, Elvis and Yuri, for editing it once again!) and all other release documentation. Any additional testing you can do and/or encourage others to do of the new and old components of 3.6 and with with third-party packages will be appreciated. Please document anything you think *might* be a release critical problem in the bug tracker marking them as "release blocker". Assuming no unresolved release critical problems arise, the final two steps will be the release candidate in 2 weeks and then, again assuming no release critical problems are identified in it, the final release on 12-16. Please contact me if you have any questions about what may or may not be appropriate to push during these final days before the release. So close! --Ned -- Ned Deily [email protected] -- [] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
