[infrastructure] Re: [development] Drupal 4.5 unsupported

[Jonathan Lambert]

Inline below...


On 5/31/06 2:53 PM, "Adrian Rossouw" <adrian at bryght.com> wrote:
> On 31 May 2006, at 11:32 PM, Khalid B wrote:
>> Simple: if we break the current API, the next release from HEAD is
>> 5.0.0.
>> If we don't, then it is 4.8.0
> Seriously. I don't think that is going to change a single thing about
> how we develop.
> To me :
> x = major architectural changes, in the form of major overhauls of
> existing systems, or powerful new systems being introduced.
>     (4.x : node, taxonomy etc , 5.x : cck, views, perhaps some
> action / workflow stuff, 6.x: sentience and self-awareness ? )
> y = api changes
> z = bug fixes

Another thread I have to jump in on.  What is the desired outcome of this
thread by the original poster?  The answer: to make sure the naming
convention is clear and consistent.

As Speck said, it's been the same for the last 3 years.  So given the
desired outcome (stability, clarity), how would changing *anything* after
three years of stable naming convention produce anything but a lose-lose for
everyone involved.  As Adrian pointed out (and it's a good point!), it
wouldn't "change a single thing" for development.

How would changing a three year old convention help make things more clear
and consistent, if the convention itself is already consistent.

Nay!  (I love that word)  The answer here is merely to make the convention
more clear (aka, documented), not to change anything if the goal truly is as
stated.

The first rule of development is not to fix it if it isn't broke.  This
ain't broke.  So there is no reason to fix it.  It might need to be
explained a little better, and it might be cool if version releases had some
explanation to how the number was arrived at on the homepage of drupal.org
(for those who are interested) when releases are posted (or in the release
notes, where, wait! It's already in there!), but beyond that, I can only see
a lose-lose for the requestors on the thread, and for the developers who
have to start thinking about something that really has minor value.

Think of it this way... What information can you derive from version release
numbers.  Minor releases can break sites.  Bug fixes and break sites.  API
Changes can break sites.  Major architecture changes WILL break sites.  Only
one of these version numbers is guaranteed to break crap when it changes.
But ALL of them are capable of breaking stuff.  That's what version release
notes are for (you do read them before upgrading right?).  So the version
number is largely semantic anyways - it merely indicates a risk level, but
the risk is always there anyways, and you should be doing the legwork before
installing, or reading the associated post with the release, or reading at a
minimum the release docs in the package, all of which cover the information
(in more depth) contained in the release number _anyways_ so what is the
point here?  

I think Adrian's system here makes tons of sense.

But I don't think there is any value in changing release numbers - from a
material, site management point of view all of the information needed to
upgrade should be in the release notes, including errata and potential site
breaking bits.  If anything, we should be harping on making better (more
consistent, more readable) release notes, not changing version numbers that
have been consistent for three years.  It's a mere mental game imho.  And
changing it would actually denigrate the stability and clarity of three
years of release management - where is the sense in that?!

Jonathan