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 nad@python.org -- []
On Nov 22, 2016, at 02:02, Ned Deily <nad@python.org> 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 nad@python.org -- []
Hi,
2016-11-22 8:24 GMT+01:00 Ned Deily <nad@python.org>:
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!
Sorry, I pushed changes before reading your email(s). I expected that release critical changes would have to be pushed to a different repository using cherry-pick or something else.
To be clear: Python 3.5 will be frozen as well? Pushing to 3.5 requires to merge into 3.6 (and then merge into default).
Four changes have been pushed after the tag:
(*) https://hg.python.org/cpython/rev/4f6fb9e47f6b Issue #28023: Fix python-gdb.py didn't support new dict implementation [#28023]
I reviewed Naoki's patch and it LGTM. python-gdb.py was simply 100% broken without this fix, and I consider that this tool is important for Python (but I didn't understood correctly the RC rules, sorry)! By the way, I also broke python-gdb.py with fast calls! I started to work on a fix, http://bugs.python.org/issue28770
(*) https://hg.python.org/cpython/rev/9b974f988c95 Issue #28023: Fix python-gdb.py on old GDB versions
... My fix for the previous commit. Sadly, it's hard to test on all GDB versions, but buildbots are here for that :-)
(*) https://hg.python.org/cpython/rev/6b43d15fd2d7 Issue #28727: Fix typo in pattern_richcompare()
Obvious bugfix spotted by Serhiy.
(*) https://hg.python.org/cpython/rev/c2cb70c97163 Issue #28727: Optimize pattern_richcompare() for a==a
This one is a minor optimization suggested by Serhiy.
Should I revert these changes? Or can someone please review them one more time?
Victor
On Nov 22, 2016, at 09:57, Victor Stinner <victor.stinner@gmail.com> wrote:
2016-11-22 8:24 GMT+01:00 Ned Deily <nad@python.org>:
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!
Sorry, I pushed changes before reading your email(s). I expected that release critical changes would have to be pushed to a different repository using cherry-pick or something else.
To be clear: Python 3.5 will be frozen as well? Pushing to 3.5 requires to merge into 3.6 (and then merge into default).
No, 3.5 is not necessarily frozen. As I noted in yesterday's first email, you have two options:
"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."
In other words, if you as a committer feel comfortable with following a non-standard workflow during the current release candidate stage, you can certainly do so, i.e. pushing to 3.5 then merging to default and then, after the 3.6 branch is free again for 3.6.1, going back and backporting to 3.6. Or, easier, just push to default for now and then backport to the 3.5 and 3.6 branches (and null merge to default) once 3.6 is free for 3.6.1 after rc1. But, it probably is just easiest for most people to hold off pushing multiple branch changes until rc1 which should happen in two weeks.
Does that make sense?
Four changes have been pushed after the tag:
(*) https://hg.python.org/cpython/rev/4f6fb9e47f6b Issue #28023: Fix python-gdb.py didn't support new dict implementation [#28023]
I reviewed Naoki's patch and it LGTM. python-gdb.py was simply 100% broken without this fix, and I consider that this tool is important for Python (but I didn't understood correctly the RC rules, sorry)! By the way, I also broke python-gdb.py with fast calls! I started to work on a fix, http://bugs.python.org/issue28770
(*) https://hg.python.org/cpython/rev/9b974f988c95 Issue #28023: Fix python-gdb.py on old GDB versions
... My fix for the previous commit. Sadly, it's hard to test on all GDB versions, but buildbots are here for that :-)
I agree with Naoki and you that fixing python-gdb.py qualifies as release critical; it's also self-contained and thus low-risk. Thanks for pushing and fixing that!
(*) https://hg.python.org/cpython/rev/6b43d15fd2d7 Issue #28727: Fix typo in pattern_richcompare()
Obvious bugfix spotted by Serhiy.
OK
(*) https://hg.python.org/cpython/rev/c2cb70c97163de. Issue #28727: Optimize pattern_richcompare() for a==a
This one is a minor optimization suggested by Serhiy.
My feeling is that this change does not meet the Release Candidate criteria and I would not have pushed it myself. But, now that it is there, I will leave it up to you and Serhiy to decide whether to revert it or not. As long as it doesn't break anything, I'll be OK with either outcome.
Thanks for your help!
--Ned
-- Ned Deily nad@python.org -- []
On Nov 22, 2016, at 6:57 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
Should I revert these changes?
I don't think reverting any of these would improve the release. I vote for them to stay.
Raymond
Ok, thank you Raymond for checking.
Victor
Le 23 nov. 2016 05:25, "Raymond Hettinger" <raymond.hettinger@gmail.com> a écrit :
On Nov 22, 2016, at 6:57 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
Should I revert these changes?
I don't think reverting any of these would improve the release. I vote for them to stay.
Raymond
On Tue, 22 Nov 2016 02:24:37 -0500, Ned Deily <nad@python.org> wrote:
On Nov 22, 2016, at 02:02, Ned Deily <nad@python.org> 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.
I'm sorry, but I find this confusing. It wasn't what I understood your previous email to mean, which means I didn't read it carefully enough and saw it through a filter of my preconceptions.
Essentially, you are making B4 act like RC1 except that you are expecting there to be fixes, and making RC1 act like RC2 with hopes that it really is final. That's fine, but we really ought to have named them RC1 and RC2 in that case.
I'm not suggesting you change your plan now, except that you should *not* open the 3.6 branch for commits until after *final* is released, in case another RC is required. Unless you plan to branch and cherry pick for an "RC2" if it is needed, which would be fine, but you should say that :)
If we in fact miss something in this really-an-RC phase (RC0?) that is revealed by the testing of RC1, then I strongly recommend against making changes to RC1 and then releasing the result as final without external testing. We've had a brown bag release in the past by doing that, for what we thought were "safe" fixes. Any "extra" RC period can be really short, though.
--David
On Nov 22, 2016, at 10:20, R. David Murray <rdmurray@bitdance.com> wrote:
I'm sorry, but I find this confusing. It wasn't what I understood your previous email to mean, which means I didn't read it carefully enough and saw it through a filter of my preconceptions.
No problem! We are doing things a bit differently this time, for several reasons as I've mentioned in previous emails.
Essentially, you are making B4 act like RC1 except that you are expecting there to be fixes, and making RC1 act like RC2 with hopes that it really is final. That's fine, but we really ought to have named them RC1 and RC2 in that case.
I think we just have a difference in terminology here and, yes, the terminology may differ somewhat from some previous releases. Beta 4 is the end of the beta stage; it is *not* a candidate to be released. There are still missing documentation changes and it contains previously unreleased and untested code. After b4, the final doc changes and a small number (we hope) of release critical code changes will go in for rc1. This is where we are right now. The goal is for rc1 to be able to be released as is, with zero changes other than the version tag. To me, that's a release candidate.
I'm not suggesting you change your plan now, except that you should *not* open the 3.6 branch for commits until after *final* is released, in case another RC is required. Unless you plan to branch and cherry pick for an "RC2" if it is needed, which would be fine, but you should say that :) If we in fact miss something in this really-an-RC phase (RC0?) that is revealed by the testing of RC1, then I strongly recommend against making changes to RC1 and then releasing the result as final without external testing. We've had a brown bag release in the past by doing that, for what we thought were "safe" fixes. Any "extra" RC period can be really short, though.
Yes, I think we are in agreement here. In the most recent email, I did not repeat everything from my earlier email in which I stated:
"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 did not explicitly talk about an rc2 but it is in the PEP as an option. The goal as I see it is for rc1 to be the same as the final release other than the version info (v3.6.0rc1 vs v3.6.0 final). So option 0 is:
- We find no release critical problems with rc1 and we retag, rebuild, and release it as 3.6.0 final.
If we do find problems with rc1, I see three additional options:
If the problem(s) are truly trivial and we agree that the risk is truly minimal (release manager gut feel, hand wave, group consultation), we can release rc1 with the trivial fix as the final without another round of testing.
If a very small number of problems are found with rc1 that are more than trivial but still "manageable" (another release manager gut feel call), we can produce an rc2 and another round of testing and then retag, rebuild, and release as 3.6.0 final.
If multiple significant problems arise, we can go back to the beta stage and do additional beta releases until we think we are ready for a new release candidate.
I am hoping for option 0, obviously. Between the time rc1 is released and up to the scheduled final release date, we will evaluate any release critical problems that arise and choose one of the other options. I share your concern about the risks of releasing untested code resulting in brown bag followups so option 1 would not be taken lightly.
The major point I want to stress is that we are going to very carefully manage what goes into 3.6.0 from now until the end of the release. I think we have had some strain on the release process in the past when we've allowed ourselves to put too many changes in the final stages of a release and I want to avoid doing that for 3.6.0. I am also counting on all of you to help by following the Release Candidate stage criteria for 3.6 changes.
Between now (the end of b4) and rc1, I am asking all of us to only push things to the 3.6 branch that should go into 3.6.0 rc1 and final, that is, reviewed release critical code fixes and final doc changes. I've opted to do this rather than totally lock down the 3.6 branch and/or accumulate changes for rc1 elsewhere because:
- the period is relatively short
- we're expecting a small number of code changes going into rc1
- so that we won't introduce further confusions with external repos et al
- so we have the benefit of our standard buildbot testing.
If you are not sure whether something is appropriate for the 3.6 branch, please ask before pushing.
Once we reach rc1, by the criteria above, there will be zero to a very very small number of changes approved post-rc1 and those will be cherry-picked and managed separately and the 3.6 branch will open again for 3.6.1 changes unless, perish the thought, we need to go back and do more betas (option 3 above).
I hope this all sounds reasonable and makes things clearer. Let me know if you have any further questions.
Thanks everyone!
--Ned
-- Ned Deily nad@python.org -- []
On Tue, 22 Nov 2016 at 09:45 Ned Deily <nad@python.org> wrote:
On Nov 22, 2016, at 10:20, R. David Murray <rdmurray@bitdance.com> wrote:
I'm sorry, but I find this confusing. It wasn't what I understood your previous email to mean, which means I didn't read it carefully enough and saw it through a filter of my preconceptions.
No problem! We are doing things a bit differently this time, for several reasons as I've mentioned in previous emails.
Essentially, you are making B4 act like RC1 except that you are expecting there to be fixes, and making RC1 act like RC2 with hopes that it really is final. That's fine, but we really ought to have named them RC1 and RC2 in that case.
I think we just have a difference in terminology here and, yes, the terminology may differ somewhat from some previous releases. Beta 4 is the end of the beta stage; it is *not* a candidate to be released. There are still missing documentation changes and it contains previously unreleased and untested code. After b4, the final doc changes and a small number (we hope) of release critical code changes will go in for rc1. This is where we are right now. The goal is for rc1 to be able to be released as is, with zero changes other than the version tag. To me, that's a release candidate.
I think for me what made everything click was realizing that we used to say "until rc1 is cut, treat it as the beta phase", while Ned is saying "since b4 is the last beta, we are now working towards the RC". I actually think Ned's approach is mentally more consistent as we are always working towards the next release which should specify the commit rules, while historically we have worked as if the *last* release dictated the commit rules *unless* it was for the final release.
-Brett
I'm not suggesting you change your plan now, except that you should *not* open the 3.6 branch for commits until after *final* is released, in case another RC is required. Unless you plan to branch and cherry pick for an "RC2" if it is needed, which would be fine, but you should say that :) If we in fact miss something in this really-an-RC phase (RC0?) that is revealed by the testing of RC1, then I strongly recommend against making changes to RC1 and then releasing the result as final without external testing. We've had a brown bag release in the past by doing that, for what we thought were "safe" fixes. Any "extra" RC period can be really short, though.
Yes, I think we are in agreement here. In the most recent email, I did not repeat everything from my earlier email in which I stated:
"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 did not explicitly talk about an rc2 but it is in the PEP as an option. The goal as I see it is for rc1 to be the same as the final release other than the version info (v3.6.0rc1 vs v3.6.0 final). So option 0 is:
- We find no release critical problems with rc1 and we retag, rebuild, and release it as 3.6.0 final.
If we do find problems with rc1, I see three additional options:
If the problem(s) are truly trivial and we agree that the risk is truly minimal (release manager gut feel, hand wave, group consultation), we can release rc1 with the trivial fix as the final without another round of testing.
If a very small number of problems are found with rc1 that are more than trivial but still "manageable" (another release manager gut feel call), we can produce an rc2 and another round of testing and then retag, rebuild, and release as 3.6.0 final.
If multiple significant problems arise, we can go back to the beta stage and do additional beta releases until we think we are ready for a new release candidate.
I am hoping for option 0, obviously. Between the time rc1 is released and up to the scheduled final release date, we will evaluate any release critical problems that arise and choose one of the other options. I share your concern about the risks of releasing untested code resulting in brown bag followups so option 1 would not be taken lightly.
The major point I want to stress is that we are going to very carefully manage what goes into 3.6.0 from now until the end of the release. I think we have had some strain on the release process in the past when we've allowed ourselves to put too many changes in the final stages of a release and I want to avoid doing that for 3.6.0. I am also counting on all of you to help by following the Release Candidate stage criteria for 3.6 changes.
Between now (the end of b4) and rc1, I am asking all of us to only push things to the 3.6 branch that should go into 3.6.0 rc1 and final, that is, reviewed release critical code fixes and final doc changes. I've opted to do this rather than totally lock down the 3.6 branch and/or accumulate changes for rc1 elsewhere because:
- the period is relatively short
- we're expecting a small number of code changes going into rc1
- so that we won't introduce further confusions with external repos et al
- so we have the benefit of our standard buildbot testing.
If you are not sure whether something is appropriate for the 3.6 branch, please ask before pushing.
Once we reach rc1, by the criteria above, there will be zero to a very very small number of changes approved post-rc1 and those will be cherry-picked and managed separately and the 3.6 branch will open again for 3.6.1 changes unless, perish the thought, we need to go back and do more betas (option 3 above).
I hope this all sounds reasonable and makes things clearer. Let me know if you have any further questions.
Thanks everyone!
--Ned
-- Ned Deily nad@python.org -- []
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On Nov 22, 2016, at 12:59, Brett Cannon <brett@python.org> wrote:
I think for me what made everything click was realizing that we used to say "until rc1 is cut, treat it as the beta phase", while Ned is saying "since b4 is the last beta, we are now working towards the RC". I actually think Ned's approach is mentally more consistent as we are always working towards the next release which should specify the commit rules, while historically we have worked as if the *last* release dictated the commit rules *unless* it was for the final release.
Yes, thanks, Brett! That is indeed my way of thinking about the release and I think it is also consistent with how we describe the Release Candidate stage in the Developer's Guide.
"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."
https://docs.python.org/devguide/devcycle.html#release-candidate-rc
But, as you hint at, that is not really the case for the Beta stage which is described thusly:
"After a first beta release is published, no new features are accepted. Only bug fixes can now be committed. This is when core developers should concentrate on the task of fixing regressions and other new issues filed by users who have downloaded the alpha and beta releases"
https://docs.python.org/devguide/devcycle.html#release-candidate-rc
Up until you pointed this out, I hadn't noticed the discrepancy between those two transitions, Alpha -> Beta and Beta -> RC. I guess for me the name "Release Candidate" makes the "working towards the RC" approach very natural. But it also seems natural to me to think of the first Beta release as the feature code cutoff (as we currently do) rather the last Alpha being the feature code cutoff and working towards the first Beta. Perhaps we can live with that bit of inconsistency? :=) We certainly could change that if enough of us find it too confusing.
The good news is that we'll have another chance to tweak things for the 3.7 release when, with the new development workflow, we should have more sophisticated tools available to manage the release endgame. I'm hopeful we'll be able to make it easier for all of us.
-- Ned Deily nad@python.org -- []
On Tue, 22 Nov 2016 13:47:35 -0500, Ned Deily <nad@python.org> wrote:
On Nov 22, 2016, at 12:59, Brett Cannon <brett@python.org> wrote:
I think for me what made everything click was realizing that we used to say "until rc1 is cut, treat it as the beta phase", while Ned is saying "since b4 is the last beta, we are now working towards the RC". I actually think Ned's approach is mentally more consistent as we are always working towards the next release which should specify the commit rules, while historically we have worked as if the *last* release dictated the commit rules *unless* it was for the final release.
Yes, thanks, Brett! That is indeed my way of thinking about the release and I think it is also consistent with how we describe the Release Candidate stage in the Developer's Guide.
OK, fair enough. It's a change in our development style, but a reasonable one. I (and Victor I presume) were fooled by the fact that it is a change, but it wasn't obvious that it was.
If we wish to use this going forward (and I think that would be reasonable), then we should document it.
Being who we are (precisionist programmers), the inconsistency between "beta release cuts off features" and "last beta before RC cuts off non-release-critical fixes" does produce some cognitive dissonance. I've seen the RC described as "the first beta that might be turned into the production release", and if you think of it that way it makes it easier to remember that we're restricting commits in order to produce that "special beta". That is probably better, conceptually, than producing an RC that we fully expect will require release-critical bug fixes because we just committed a bunch of non-release-critical bug fixes, just so cutoff-when-the-name-changes stays consistent.
--David
On 22Nov2016 1150, R. David Murray wrote:
Being who we are (precisionist programmers), the inconsistency between "beta release cuts off features" and "last beta before RC cuts off non-release-critical fixes" does produce some cognitive dissonance. I've seen the RC described as "the first beta that might be turned into the production release", and if you think of it that way it makes it easier to remember that we're restricting commits in order to produce that "special beta". That is probably better, conceptually, than producing an RC that we fully expect will require release-critical bug fixes because we just committed a bunch of non-release-critical bug fixes, just so cutoff-when-the-name-changes stays consistent.
It might also help if the version info was updated to (for example) "3.6.0rc1-" rather than "3.6.0b4+", to emphasize that any work going on in that branch is work against RC and not against a beta.
I'm not sure that a trailing '-' is the right way to mark this. Maybe "rc1+dev" or similar?
Cheers, Steve
If we want the version to be PEP 440 compliant it'd be like 3.6rc1.dev0 or so if I remember correctly.
Sent from my iPhone
On Nov 22, 2016, at 3:40 PM, Steve Dower <steve.dower@python.org> wrote:
On 22Nov2016 1150, R. David Murray wrote: Being who we are (precisionist programmers), the inconsistency between "beta release cuts off features" and "last beta before RC cuts off non-release-critical fixes" does produce some cognitive dissonance. I've seen the RC described as "the first beta that might be turned into the production release", and if you think of it that way it makes it easier to remember that we're restricting commits in order to produce that "special beta". That is probably better, conceptually, than producing an RC that we fully expect will require release-critical bug fixes because we just committed a bunch of non-release-critical bug fixes, just so cutoff-when-the-name-changes stays consistent.
It might also help if the version info was updated to (for example) "3.6.0rc1-" rather than "3.6.0b4+", to emphasize that any work going on in that branch is work against RC and not against a beta.
I'm not sure that a trailing '-' is the right way to mark this. Maybe "rc1+dev" or similar?
Cheers, Steve
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On 23 November 2016 at 06:40, Steve Dower <steve.dower@python.org> wrote:
On 22Nov2016 1150, R. David Murray wrote:
Being who we are (precisionist programmers), the inconsistency between "beta release cuts off features" and "last beta before RC cuts off non-release-critical fixes" does produce some cognitive dissonance. I've seen the RC described as "the first beta that might be turned into the production release", and if you think of it that way it makes it easier to remember that we're restricting commits in order to produce that "special beta". That is probably better, conceptually, than producing an RC that we fully expect will require release-critical bug fixes because we just committed a bunch of non-release-critical bug fixes, just so cutoff-when-the-name-changes stays consistent.
It might also help if the version info was updated to (for example) "3.6.0rc1-" rather than "3.6.0b4+", to emphasize that any work going on in that branch is work against RC and not against a beta.
I'm not sure that a trailing '-' is the right way to mark this. Maybe "rc1+dev" or similar?
The "3.6.0rc0+" notation would reflect that it's not a beta any more, but still comes before rc1.
(While Donald's right that PEP 440 recommends a ".dev0" suffix for this use case, we don't allow for that in the interpreter level version reporting APIs, while an "rc0" suffix should work fine)
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (8)
-
Brett Cannon -
Donald Stufft -
Ned Deily -
Nick Coghlan -
R. David Murray -
Raymond Hettinger -
Steve Dower -
Victor Stinner