[drupal-devel] Tight release cycles

Gerhard Killesreiter killesreiter at physik.uni-freiburg.de
Mon Jul 25 09:06:57 UTC 2005

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.


More information about the drupal-devel mailing list