[drupal-devel] Tight release cycles
Hi! Let's start making a calendar for next year's releases now and stick to it. My proposal: 2005 dec 26 code freeze (or Jan 2, 2006) 2006 feb 6 Drupal 4.8 2006 may 1 code freeze 2006 june 5 Drupal 4.9 2006 aug 28 code freeze 2006 oct 2 Drupal 5.0 2007 jan 1 code freeze 2007 feb 5 Drupal 5.1 ... We always have five weeks for bug fixing and three months of features. Let's give active support for actual release and security fixes for one version behind and two versions back is simply not supported. Regards NK
afair there has been a nice tradition to release on first day of the month. Looks good in the calendar apps, too ;) k
Op zondag 24 juli 2005 11:10, schreef Karoly Negyesi:
version behind and two versions back is simply not supported.
Three versions back, I mean.
This mirrors what we have now: we maintain 4.6, provide security fixes for 4.5 and 4.4 is dead.
Yes, But what CHX proposes is to make the current practice "oficial". Write it down and stick to it. I like that. For people depending on drupal (like me, bryght, and loads of other core developers) for their own plannings, having this more official would help a lot. +1 on Charlies calendar. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Let's start making a calendar for next year's releases now and stick to it.
My proposal:
2005 dec 26 code freeze (or Jan 2, 2006) 2006 feb 6 Drupal 4.8 2006 may 1 code freeze 2006 june 5 Drupal 4.9 2006 aug 28 code freeze 2006 oct 2 Drupal 5.0 2007 jan 1 code freeze 2007 feb 5 Drupal 5.1 ...
We always have five weeks for bug fixing and three months of features.
Let's give active support for actual release and security fixes for one version behind and two versions back is simply not supported.
Funny, but the most interesting item for me would be the 4.7 code freeze and release date :) I know it might be impossible to tell yet, but some date range is probably possible to be provided. I guess more people are like me, but they had no time yet to express that. Anyway, back to topic, I am unsure that Drupal 5.0 should be used for the name of the release coming after Drupal 4.9, just because the second digit overflows. Otherwise I am +1 on a predictable release cycle. Also three releases for 2006 seems to be good, it is more than what we are going to do in 2005, which should be positive for Killes I guess :) Goba
On Sun, 24 Jul 2005, Karoly Negyesi wrote:
Let's start making a calendar for next year's releases now and stick to it.
My proposal:
2005 dec 26 code freeze (or Jan 2, 2006) 2006 feb 6 Drupal 4.8 2006 may 1 code freeze 2006 june 5 Drupal 4.9 2006 aug 28 code freeze 2006 oct 2 Drupal 5.0 2007 jan 1 code freeze 2007 feb 5 Drupal 5.1 ...
We always have five weeks for bug fixing and three months of features.
I obviously like the idea. More releases would mean that new features would be faster available to users and the requests for backports would go down. Since the changes between releases wouldn't be that big anymore the needed work per upgrade would also be less. Cheers, Gerhard
On 24-Jul-05, at 2:06 AM, Karoly Negyesi wrote:
Let's start making a calendar for next year's releases now and stick to it.
My proposal:
2005 dec 26 code freeze (or Jan 2, 2006) 2006 feb 6 Drupal 4.8 2006 may 1 code freeze 2006 june 5 Drupal 4.9 2006 aug 28 code freeze 2006 oct 2 Drupal 5.0 2007 jan 1 code freeze 2007 feb 5 Drupal 5.1 ...
We always have five weeks for bug fixing and three months of features.
Urgh. I actually think there are a *ton* of fixes to be made inside of releases...e.g. the x.x.1 release tends to be much more solid in the last couple of releases. Also, there are many many many innovations being down outside of core, many of them much more "wow" than a solid, stable, feature rich core. A really solid core with "cool" contribs is perhaps something to consider. What this means is more revisions around core and maybe even point releases that (gasp!) have the sort of "backport" features that we have up until now held for major releases. One example of this is "free tagging" support.
Let's give active support for actual release and security fixes for one version behind and two versions back is simply not supported.
I'm +1 for this in principal...but shorter release cycles means that by Feb 2006, 4.6 will no longer be supported. I don't think that is a good thing. I think my proposal for point releases that include "features" would make this less of a problem as well. -- Boris Mann http://www.bmannconsulting.com
On Sun, 24 Jul 2005, Boris Mann wrote:
On 24-Jul-05, at 2:06 AM, Karoly Negyesi wrote:
Let's start making a calendar for next year's releases now and stick to it.
My proposal:
2005 dec 26 code freeze (or Jan 2, 2006) 2006 feb 6 Drupal 4.8 2006 may 1 code freeze 2006 june 5 Drupal 4.9 2006 aug 28 code freeze 2006 oct 2 Drupal 5.0 2007 jan 1 code freeze 2007 feb 5 Drupal 5.1 ...
We always have five weeks for bug fixing and three months of features.
Urgh. I actually think there are a *ton* of fixes to be made inside of releases...e.g. the x.x.1 release tends to be much more solid in the last couple of releases.
That's true for any software. The problem is that we cannot get people to test the RCs.
Also, there are many many many innovations being down outside of core, many of them much more "wow" than a solid, stable, feature rich core. A really solid core with "cool" contribs is perhaps something to consider.
I always was under the impression that we have this.
What this means is more revisions around core and maybe even point releases that (gasp!) have the sort of "backport" features that we have up until now held for major releases. One example of this is "free tagging" support.
Excellent example. Will you do the support for all the people who used this backport and cannot get Drupal to upgrade to the next version because of it? Or will you rewrite update.php to check for this kind of inconsistencies in the database?
Let's give active support for actual release and security fixes for one version behind and two versions back is simply not supported.
I'm +1 for this in principal...but shorter release cycles means that by Feb 2006, 4.6 will no longer be supported.
Since the changes to each version would be smaller, we could maybe support three versions. Support in the sense that we provide security related fixes.
I don't think that is a good thing. I think my proposal for point releases that include "features" would make this less of a problem as well.
As this proposal stands now it is mere sales talk. Don't get me wrong: I like selling Drupal too, but I try to be realistic about it. I don't think we have the manpower to do both three releases a year _and_ support backports. Cheers, Gerhard
I won't switch to strict time-based releases, nor to strict feature- based releases, though I'm willing to lean more towards time-based releases. I very much prefer to release when (i) we made enough improvements and (ii) it has been a while since we released a new version. Contrary to what some people say, the Drupal release schedule has been fairly predictable for those who are part of the Drupal community. That said, I was planning to announce a new code freeze shortly -- I meant to do it last week but was swamped with work. Either way, I was thinking about starting the next code freeze on September 1 (5 weeks from now). This means Drupal 4.7 will be released somewhere in October or November. On 24 Jul 2005, at 11:06, Karoly Negyesi wrote:
Let's start making a calendar for next year's releases now and stick to it.
My proposal:
2005 dec 26 code freeze (or Jan 2, 2006) 2006 feb 6 Drupal 4.8 2006 may 1 code freeze 2006 june 5 Drupal 4.9 2006 aug 28 code freeze 2006 oct 2 Drupal 5.0 2007 jan 1 code freeze 2007 feb 5 Drupal 5.1 ...
-- Dries Buytaert :: http://www.buytaert.net/
I would personally like to request a code freeze at least one week earlier than that; the second week of August would be nice. My reasons are mostly but not completely selfish. -Robert Dries Buytaert wrote:
I won't switch to strict time-based releases, nor to strict feature- based releases, though I'm willing to lean more towards time-based releases. I very much prefer to release when (i) we made enough improvements and (ii) it has been a while since we released a new version. Contrary to what some people say, the Drupal release schedule has been fairly predictable for those who are part of the Drupal community.
That said, I was planning to announce a new code freeze shortly -- I meant to do it last week but was swamped with work. Either way, I was thinking about starting the next code freeze on September 1 (5 weeks from now). This means Drupal 4.7 will be released somewhere in October or November.
On 24 Jul 2005, at 11:06, Karoly Negyesi wrote:
Let's start making a calendar for next year's releases now and stick to it.
My proposal:
2005 dec 26 code freeze (or Jan 2, 2006) 2006 feb 6 Drupal 4.8 2006 may 1 code freeze 2006 june 5 Drupal 4.9 2006 aug 28 code freeze 2006 oct 2 Drupal 5.0 2007 jan 1 code freeze 2007 feb 5 Drupal 5.1 ...
-- Dries Buytaert :: http://www.buytaert.net/
On Tuesday 26 July 2005 12:28, Robert Douglass wrote:
I would personally like to request a code freeze at least one week earlier than that; the second week of August would be nice. My reasons
thinking about starting the next code freeze on September 1 (5 weeks
Robert, please recalculate. Aug 8 is very far from Sept 1... I also hoped for sg like Aug 15-22 but, Dries is the boss :)
On 26 Jul 2005, at 13:18, Karoly Negyesi wrote:
I would personally like to request a code freeze at least one week earlier than that; the second week of August would be nice. My reasons
thinking about starting the next code freeze on September 1 (5 weeks
Robert, please recalculate. Aug 8 is very far from Sept 1... I also hoped for sg like Aug 15-22 but, Dries is the boss :)
I'm open for suggestions/discussion, and don't mind setting another date if that is favored. -- Dries Buytaert :: http://www.buytaert.net/
Op dinsdag 26 juli 2005 15:15, schreef Dries Buytaert:
I'm open for suggestions/discussion, and don't mind setting another date if that is favored.
Maybe we should look at * what we have now, compare to 4.6 * what we really cannot miss in 4.7 And then set a date that is realistic when taken the last list in mind. I beleive we have more then enought somehow finished patches in teh queue to get a fabulous 4.7 out of them. But IMO the only one that shuold go in for 4.7 is "put revisions in own table". Acc to me t§he code freeze can take place after that. But suerly others have good patches that they need to see in 4.7? Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On Tue, 26 Jul 2005 15:24:12 +0200, Bèr Kessels <berdrupal@tiscali.be> wrote:
Op dinsdag 26 juli 2005 15:15, schreef Dries Buytaert:
I'm open for suggestions/discussion, and don't mind setting another date if that is favored.
Maybe we should look at * what we have now, compare to 4.6 * what we really cannot miss in 4.7
And then set a date that is realistic when taken the last list in mind.
I beleive we have more then enought somehow finished patches in teh queue to get a fabulous 4.7 out of them. But IMO the only one that shuold go in for 4.7 is "put revisions in own table". Acc to me t§he code freeze can take place after that. But suerly others have good patches that they need to see in 4.7?
I'd like to know if http://drupal.org/node/25756 will be considered for core. If so, I'd like to try to get it in 4.7. -- Tim Altman
On Tue, 26 Jul 2005, Dries Buytaert wrote:
On 26 Jul 2005, at 13:18, Karoly Negyesi wrote:
Robert, please recalculate. Aug 8 is very far from Sept 1... I also hoped for sg like Aug 15-22 but, Dries is the boss :)
I'm open for suggestions/discussion, and don't mind setting another date if that is favored.
There are two things that we IMNSHO need to get into it before feature freeze: 1) form rewrite 2) revisions ;) Both probably will take a while (1 more than 2). Cheers, Gerhard
Op 26-jul-2005, om 15:53 heeft Gerhard Killesreiter het volgende geschreven:
On Tue, 26 Jul 2005, Dries Buytaert wrote:
On 26 Jul 2005, at 13:18, Karoly Negyesi wrote:
Robert, please recalculate. Aug 8 is very far from Sept 1... I also hoped for sg like Aug 15-22 but, Dries is the boss :)
I'm open for suggestions/discussion, and don't mind setting another date if that is favored.
There are two things that we IMNSHO need to get into it before feature freeze:
1) form rewrite 2) revisions ;)
And how about Adrians install api, where everybody is waiting for after the release of drupal 4.0? Stefan
There are two things that we IMNSHO need to get into it before feature freeze:
1) form rewrite 2) revisions ;)
And how about Adrians install api, where everybody is waiting for after the release of drupal 4.0?
Have you seen significant progress in this area recently. Maybe I am too ignorant, but I have not seen this improving much. Goba
On Tue, 26 Jul 2005, Stefan Nagtegaal wrote:
Op 26-jul-2005, om 15:53 heeft Gerhard Killesreiter het volgende geschreven:
There are two things that we IMNSHO need to get into it before feature freeze:
1) form rewrite 2) revisions ;)
And how about Adrians install api, where everybody is waiting for after the release of drupal 4.0?
Neil is now working on it. Since Civicspace wants it it is likely to be completed rather sooner than later. Maybe it will be in time for the feature freeze. Cheers, Gerhard
On Tue, Jul 26, 2005 at 06:24:49PM +0200, Gerhard Killesreiter wrote:
On Tue, 26 Jul 2005, Stefan Nagtegaal wrote:
Op 26-jul-2005, om 15:53 heeft Gerhard Killesreiter het volgende geschreven:
There are two things that we IMNSHO need to get into it before feature freeze:
1) form rewrite 2) revisions ;)
And how about Adrians install api, where everybody is waiting for after the release of drupal 4.0?
Neil is now working on it. Since Civicspace wants it it is likely to be completed rather sooner than later. Maybe it will be in time for the feature freeze.
A summary of the update.php screens: http://flickr.com/photos/drumm/28798226/ A summary of the currently planned patches: http://flickr.com/photos/drumm/28799551/ The currently pending patch: http://drupal.org/node/27231 -Neil
participants (11)
-
Boris Mann -
Bèr Kessels -
Dries Buytaert -
Gabor Hojtsy -
Gerhard Killesreiter -
Karoly Negyesi -
Kristjan Jansen -
neil＠civicspacelabs.org -
Robert Douglass -
Stefan Nagtegaal -
Tim Altman