I've recently seen a couple of references to 3.1.2 go by in checkins which made me wonder whether dates have been proposed yet for updates to either 3.1 or 2.6. I don't recall seeing any and I didn't see any references in the PEPs. Some advance warning would be nice. I assume that some critical problem could trigger planning for an update on short notice; is there a time-limit trigger as well? -- Ned Deily, nad@acm.org
Ned Deily wrote:
I've recently seen a couple of references to 3.1.2 go by in checkins which made me wonder whether dates have been proposed yet for updates to either 3.1 or 2.6. I don't recall seeing any and I didn't see any references in the PEPs. Some advance warning would be nice. I assume that some critical problem could trigger planning for an update on short notice; is there a time-limit trigger as well?
Usually there is one more regular maintenance release of the existing maintenance branches within a few months of the creation of the next version (releases before then are at the discretion of the release manager, and security releases continue for much longer). So take the planned 2.7 and 3.2 release dates and add a couple of months to each one to get the likely release dates for the 2.6.x and 3.1.x maintenance releases. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Ned Deily wrote:
I've recently seen a couple of references to 3.1.2 go by in checkins which made me wonder whether dates have been proposed yet for updates to either 3.1 or 2.6. I don't recall seeing any and I didn't see any references in the PEPs. Some advance warning would be nice. I assume that some critical problem could trigger planning for an update on short notice; is there a time-limit trigger as well?
Barry was once proposing time-based releases; this idea didn't really catch on. It's the release manager who decides when the next bug fix release will be made, often in response to developers asking for one. Regards, Martin
Ned Deily
I've recently seen a couple of references to 3.1.2 go by in checkins which made me wonder whether dates have been proposed yet for updates to either 3.1 or 2.6. I don't recall seeing any and I didn't see any references in the PEPs. Some advance warning would be nice.
There are a couple of release blockers right now. Once they are fixed or deferred, I think it would be nice to have a 3.1.2. Why do you need "some advance warning" though?
Antoine Pitrou wrote:
Ned Deily
writes: I've recently seen a couple of references to 3.1.2 go by in checkins which made me wonder whether dates have been proposed yet for updates to either 3.1 or 2.6. I don't recall seeing any and I didn't see any references in the PEPs. Some advance warning would be nice.
There are a couple of release blockers right now. Once they are fixed or deferred, I think it would be nice to have a 3.1.2. Why do you need "some advance warning" though?
Advance warning does allow interested users that would consider upgrading to schedule time for testing before the maintenance release comes out. This is particularly useful in helping to make a 1-week RC period effective in picking up issues that might otherwise lead to a brown paper bag release to fix major issues that slipped through our own automated test coverage. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
In article <4B53135A.7060104@gmail.com>,
Nick Coghlan
Antoine Pitrou wrote:
Ned Deily
writes: I've recently seen a couple of references to 3.1.2 go by in checkins which made me wonder whether dates have been proposed yet for updates to either 3.1 or 2.6. I don't recall seeing any and I didn't see any references in the PEPs. Some advance warning would be nice. There are a couple of release blockers right now. Once they are fixed or deferred, I think it would be nice to have a 3.1.2. Why do you need "some advance warning" though?
Advance warning does allow interested users that would consider upgrading to schedule time for testing before the maintenance release comes out. This is particularly useful in helping to make a 1-week RC period effective in picking up issues that might otherwise lead to a brown paper bag release to fix major issues that slipped through our own automated test coverage.
That. and resource contention: there are always potential fixes in the pipeline that could or should be bumped in priority if one knows there is a code cutoff approaching. -- Ned Deily, nad@acm.org
On Jan 17, 2010, at 4:21 AM, Martin v. Löwis wrote:
Barry was once proposing time-based releases; this idea didn't really catch on.
I'm still a proponent of this, but it doesn't seem like there's enough support for it.
It's the release manager who decides when the next bug fix release will be made, often in response to developers asking for one.
I'm happy to make a 2.6.5 release whenever it makes sense. -Barry
participants (5)
-
"Martin v. Löwis" -
Antoine Pitrou -
Barry Warsaw -
Ned Deily -
Nick Coghlan