[infrastructure] Re: [development] Drupal 4.5 unsupported

[Larry Garfield]

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