Inline below... On 5/31/06 2:53 PM, "Adrian Rossouw" <adrian@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