[infrastructure] Re: [development] Drupal 4.5 unsupported
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
> > 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
> 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