Should we plan to put out a final 2.5 release? If so, should we continue to backport fixes (like Martin's removal of Alpha in setup.py)? My preference is that we do put out a final 2.5 that has all accumulated bug fixes. Then close the branch. That way if we put out a security release for 2.5, it will be clean and easy. n
Neal> Should we plan to put out a final 2.5 release? I'm probably a bad person to ask. At work we are still using 2.4. :-/ Skip
[Neal Norwitz]
Should we plan to put out a final 2.5 release? If so, should we continue to backport fixes (like Martin's removal of Alpha in setup.py)? My preference is that we do put out a final 2.5 that has all accumulated bug fixes. Then close the branch. That way if we put out a security release for 2.5, it will be clean and easy.
The 2.6/3.0 development process was so disruptive that I doubt that 2.5 received adequate attention for bug fixes. Why not wait two or three months for the dust to settle? Raymond
The 2.6/3.0 development process was so disruptive that I doubt that 2.5 received adequate attention for bug fixes. Why not wait two or three months for the dust to settle?
Would it receive more attention in the next three months? Who specifically would give it that attention? Regards, Martin
On Mon, Oct 06, 2008 at 12:53:01PM -0700, Raymond Hettinger wrote:
The 2.6/3.0 development process was so disruptive that I doubt that 2.5 received adequate attention for bug fixes. Why not wait two or three months for the dust to settle?
Can you please clarify your meaning? Do you mean that * we haven't been backporting fixes to 2.5? * we should wait to see if any horrible problems are reported in 2.6? * we need to look at the logs for commits that should be applied to 2.5? --amk
[A.M. Kuchling]
Can you please clarify your meaning? Do you mean that
* we haven't been backporting fixes to 2.5?
Unsure. I surely have given zero attention to 2.5.
* we should wait to see if any horrible problems are reported in 2.6?
Yes. That would be a great idea.
* we need to look at the logs for commits that should be applied to 2.5?
Yes. That would be a great idea too. ISTM, that 3.0 and 2.6 backports have consumed substantial developer attention over the last few months.
ISTM, that 3.0 and 2.6 backports have consumed substantial developer attention over the last few months.
Sure - but who is going to sit down and study the commit logs, to do backporting? Unless someone specifically volunteers to do that (with a specific timeline when he will start, and when he will complete), I see little chance that that any additional backporting will happen. I will send an announcement asking people to propose missing backports. Regards, Martin
Raymond Hettinger <python <at> rcn.com> writes:
The 2.6/3.0 development process was so disruptive that I doubt that 2.5 received adequate attention for bug fixes. Why not wait two or three months for the dust to settle?
I know that I, and a couple of others, have tried to backport "important" bug fixes (by that I mean security fixes, crashers, memory leaks, as well as glaring behaviour problems) to 2.5 when there was no risk to reduce stability or compatibility. It's also true that 2.6/3.0 were so disruptive that the reason why few things were backported is simply that few things could be backported at all. Most checkins were related to new functionality or modified behaviour, or new bugs introduced by either of those. Everyone can look at http://code.python.org/hg/branches/release2.5-maint/shortlog to get an idea of where 2.5 is. 2.5.2 was tagged ~7 months ago. Regards Antoine.
Neal Norwitz wrote:
Should we plan to put out a final 2.5 release? If so, should we continue to backport fixes (like Martin's removal of Alpha in setup.py)? My preference is that we do put out a final 2.5 that has all accumulated bug fixes. Then close the branch. That way if we put out a security release for 2.5, it will be clean and easy.
That is my plan also. I would like to release 2.5.2 two weeks after Python 3.0, or on November 1st, whatever happens later (and it seems that Python-3-plus-two-weeks happens later). So one week after Python 3, there would be a release candidate, and two weeks, the final release. Simultaneously, I would also release 2.4.6. If people think 2.5.2 should be released earlier than that, please let me know. Regards, Martin
Martin v. Löwis wrote:
Neal Norwitz wrote:
Should we plan to put out a final 2.5 release? If so, should we continue to backport fixes (like Martin's removal of Alpha in setup.py)? My preference is that we do put out a final 2.5 that has all accumulated bug fixes. Then close the branch. That way if we put out a security release for 2.5, it will be clean and easy.
That is my plan also. I would like to release 2.5.2 two weeks after Python 3.0, or on November 1st, whatever happens later (and it seems that Python-3-plus-two-weeks happens later).
You of course meant 2.5.3.
participants (7)
-
"Martin v. Löwis" -
A.M. Kuchling -
Antoine Pitrou -
Neal Norwitz -
Raymond Hettinger -
skip＠pobox.com -
Terry Reedy