[infrastructure] Re: [development] Drupal 4.5 unsupported

[Corey Bordelon]

So pardon my ignorance, but what would be a big enough change to constitute
a incrementing X under the current versioning system?
I wasn't around for the last changes to that X version number, so I wouldn't
know.

On 5/31/06, Jonathan Lambert <j at firebright.com> wrote:
>
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20060531/3e5b6118/attachment.htm