[infrastructure] Re: [development] Drupal 4.5 unsupported
corey.bordelon at gmail.com
Wed May 31 22:35:20 UTC 2006
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
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
> 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
> 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
> 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
> 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
> 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
> 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
> installing, or reading the associated post with the release, or reading at
> minimum the release docs in the package, all of which cover the
> (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
> breaking bits. If anything, we should be harping on making better (more
> consistent, more readable) release notes, not changing version numbers
> 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?!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the development