[infrastructure] Re: [development] Drupal 4.5 unsupported

Steven Peck speck at blkmtn.org
Wed May 31 18:31:33 UTC 2006


> -----Original Message-----
> From: development-bounces at drupal.org 
> [mailto:development-bounces at drupal.org] On Behalf Of Larry Garfield
> Sent: Tuesday, May 30, 2006 10:48 AM
> To: development at drupal.org
> Subject: Re: [infrastructure] Re: [development] Drupal 4.5 unsupported
> On Tue, May 30, 2006 8:59 am, Khalid B said:
> > On 5/30/06, blogdiva at culturekitchen.com 
> <blogdiva at culturekitchen.com>
> > wrote:
> >> That's an awesome question. I'd like to hear from 
> developers and the
> >> people in the marketing team. The question is at the core of what I
> >> feel Drupal is overlooking at the moment --code freezes.
> >
> > Code freezes do happen. Once we have a release, its API 
> does not change
> > (may be a tiny bit occasionally, but not normally).
> >
> > What we do not freeze is APIs between releases. How can we 
> move forward
> > from 4.7 to 6.6 with the API remaining the same? Where would the new
> > stuff go? Are you advocating we keep APIs forever?
> >
> > Read my comment here on where the energy should be focussed 
> (migration
> > tools,
> > transitional releases, and compatibility layers).
> >
> > http://baheyeldin.com/node/617
> Honestly, I think part of the issue with the "stable API" 
> question is that
> Drupal uses version numbers differently from many projects.  
> The de facto
> standard for version numbers for most projects is 
> Major.Minor.Bug / x.y.z.
> Z increases only fix bugs.
> Y increases add features, but don't break backward 
> compatibility with 3rd
> party code.
> X increases, all bets are off.
> Witness, for instance, KDE, which has evolved and improved 
> dramatically in
> the 3.y.z cycle, but code for 3.0.0 still (generally) works 
> in 3.5.1.  For
> the upcoming 4.0, howver, there are no "sacred cows" and 
> everything will
> need to be updated.
> For Drupal, Y increases, all bets are off.  We technically 
> don't have Y
> releases, just Z and X, but we use both of the first two 
> numbers for the X
> releases.  That throws a lot of people off.  It actually 
> surprised me a
> great deal, although fortunately it didn't affect my plans 
> significantly.
> Whatever else we do, we should probably make that clearer 
> right up front. 
> It's not inherently a bad development model, just an 
> unconventional one
> that needs to be made clearer.
> --Larry Garfield

How much more clear can I make this? 
The alias is recent but it has been at the top level of the handbook now
for about a year.  Should we link it in the Project download page for

There are other projects that use different from KDE versioning release
scheme's as well.  Drupal's been consistent for the 3 years I've used it
with it's versioning information and method.  The versioning scheme has
not changed at all. 


More information about the development mailing list