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