[RELEASED] Python 3.2.6rc1, Python 3.3.6rc1
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On behalf of the Python development team, I'm happy to announce the release of Python 3.2.6rc1 and 3.3.6rc1. Both are release candidates for security-fix releases, which are provide source-only on python.org.
The list of security-related issues fixed in the releases is given in the changelogs:
https://hg.python.org/cpython/raw-file/v3.2.6rc1/Misc/NEWS
https://hg.python.org/cpython/raw-file/v3.3.6rc1/Misc/NEWSTo download the pre-releases visit one of:
https://www.python.org/downloads/release/python-326rc1/
https://www.python.org/downloads/release/python-336rc1/These are pre-releases, please report any bugs to
http://bugs.python.org/The final releases are scheduled one week from now.
Enjoy!
Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and contributors) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iEYEARECAAYFAlQv9GsACgkQN9GcIYhpnLC93gCfVm74lhOysPYCO0fy9/l5LUfJ bUYAn2u1EygfsPw2oa4CSoj5t0TYUJq7 =HnOK -----END PGP SIGNATURE-----
Larry, saw your discussion on IRC with Georg about what to cherry pick into the release clone before issuing final. IMO you shouldn't cherry pick anything, since I believe there have been *zero* issues opened that said that the RC was broken. IMO the only differences between the last RC and final should be things that would otherwise cause a "brown bag release" (ie: broken as shipped)[*]. Bug fixes subsequent to the RC (including doc fixes) should just wait until the next release.
Of course, I am one of the more pedantic of the developers about this topic, and have not served as an RM, so your mileage may vary :)
--David
[*] And I would argue that you then should have another RC before the (then unchanged except for version number) final, but I've given up on that :)
Le 05/10/2014 16:11, R. David Murray a écrit :
Larry, saw your discussion on IRC with Georg about what to cherry pick into the release clone before issuing final. IMO you shouldn't cherry pick anything, since I believe there have been *zero* issues opened that said that the RC was broken. IMO the only differences between the last RC and final should be things that would otherwise cause a "brown bag release" (ie: broken as shipped)[*]. Bug fixes subsequent to the RC (including doc fixes) should just wait until the next release.
Of course, I am one of the more pedantic of the developers about this topic, and have not served as an RM, so your mileage may vary :)
I don't know if I'm pedantic as well, but I agree with David.
Regards
Antoine.
On 10/05/2014 07:11 AM, R. David Murray wrote:
Larry, saw your discussion on IRC with Georg about what to cherry pick into the release clone before issuing final. IMO you shouldn't cherry pick anything, since I believe there have been *zero* issues opened that said that the RC was broken.
3.4.2 has been tagged, and the only changes since 3.4.2rc1 are:
- Martin made a small fix in the Windows installer build script
- I rebuilt pydoc-topics correctly
- Some minor doc touchups (fix "make suspicious" output so it runs clean)
I did make a pass over all the checkins to 3.4 since 3.4.2rc1, and found eighteen that I considered cherry-picking. Five were crashes, four were nice-to-haves, four were asyncio changes, and five just seemed small and reasonable. But nobody was begging me to pull anything in particular, and I'd like to have a nice easy release for once. So I didn't cherry-pick anything.
I also didn't want to add another RC and slip the release--Matthias said he wanted to ship 3.4.2 with Ubuntu 14.10, but with their release only about two weeks away I didn't want to stress them out any more than necessary. (One might say, "Ubuntu's release schedule is irrelevant, you should do what's best for Python". To that I'd reply, "They asked nicely, and nobody else was asking for anything, so it seemed reasonable to accommodate them, and this will get 3.4.2 into the hands of a lot of people".)
Cheers,
//arry/
On 6 October 2014 13:17, Larry Hastings larry@hastings.org wrote:
I also didn't want to add another RC and slip the release--Matthias said he wanted to ship 3.4.2 with Ubuntu 14.10, but with their release only about two weeks away I didn't want to stress them out any more than necessary. (One might say, "Ubuntu's release schedule is irrelevant, you should do what's best for Python". To that I'd reply, "They asked nicely, and nobody else was asking for anything, so it seemed reasonable to accommodate them, and this will get 3.4.2 into the hands of a lot of people".)
I may be a touch (*cough*totally*cough*) biased, but attempting to accommodate redistributors when it doesn't place any excessive demands on the upstream release cycle sounds like a fine approach to me :)
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 10/6/2014 1:15 AM, Nick Coghlan wrote:
On 6 October 2014 13:17, Larry Hastings larry@hastings.org wrote:
I also didn't want to add another RC and slip the release--Matthias said he wanted to ship 3.4.2 with Ubuntu 14.10, but with their release only about two weeks away I didn't want to stress them out any more than necessary. (One might say, "Ubuntu's release schedule is irrelevant, you should do what's best for Python". To that I'd reply, "They asked nicely, and nobody else was asking for anything, so it seemed reasonable to accommodate them, and this will get 3.4.2 into the hands of a lot of people".)
I may be a touch (*cough*totally*cough*) biased, but attempting to accommodate redistributors when it doesn't place any excessive demands on the upstream release cycle sounds like a fine approach to me :)
I don't have that bias, and I think that finalizing an apparently good candidate -- and doing 3.4.3 in about 4 months, is the right thing anyway. If there were a .rc2 released, it would not be guaranteed to be free of problems, and it would likely be followed by more 'nice to have' features.
participants (6)
-
Antoine Pitrou -
Georg Brandl -
Larry Hastings -
Nick Coghlan -
R. David Murray -
Terry Reedy