So pardon my ignorance, but what would be a big enough change to constitute a incrementing X under the current versioning system? <br>I wasn't around for the last changes to that X version number, so I wouldn't know.<br><br>
<div><span class="gmail_quote">On 5/31/06, <b class="gmail_sendername">Jonathan Lambert</b> <<a href="mailto:j@firebright.com">j@firebright.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Inline below...<br><br><br>On 5/31/06 2:53 PM, "Adrian Rossouw" <<a href="mailto:adrian@bryght.com">adrian@bryght.com</a>> wrote:<br>> On 31 May 2006, at 11:32 PM, Khalid B wrote:<br>>> Simple: if we break the current API, the next release from HEAD is
<br>>> 5.0.0.<br>>> If we don't, then it is 4.8.0<br>> Seriously. I don't think that is going to change a single thing about<br>> how we develop.<br>> To me :<br>> x = major architectural changes, in the form of major overhauls of
<br>> existing systems, or powerful new systems being introduced.<br>> (4.x : node, taxonomy etc , 5.x : cck, views, perhaps some<br>> action / workflow stuff, 6.x: sentience and self-awareness ? )<br>> y = api changes
<br>> z = bug fixes<br><br>Another thread I have to jump in on. What is the desired outcome of this<br>thread by the original poster? The answer: to make sure the naming<br>convention is clear and consistent.<br><br>
As Speck said, it's been the same for the last 3 years. So given the<br>desired outcome (stability, clarity), how would changing *anything* after<br>three years of stable naming convention produce anything but a lose-lose for
<br>everyone involved. As Adrian pointed out (and it's a good point!), it<br>wouldn't "change a single thing" for development.<br><br>How would changing a three year old convention help make things more clear<br>
and consistent, if the convention itself is already consistent.<br><br>Nay! (I love that word) The answer here is merely to make the convention<br>more clear (aka, documented), not to change anything if the goal truly is as
<br>stated.<br><br>The first rule of development is not to fix it if it isn't broke. This<br>ain't broke. So there is no reason to fix it. It might need to be<br>explained a little better, and it might be cool if version releases had some
<br>explanation to how the number was arrived at on the homepage of <a href="http://drupal.org">drupal.org</a><br>(for those who are interested) when releases are posted (or in the release<br>notes, where, wait! It's already in there!), but beyond that, I can only see
<br>a lose-lose for the requestors on the thread, and for the developers who<br>have to start thinking about something that really has minor value.<br><br>Think of it this way... What information can you derive from version release
<br>numbers. Minor releases can break sites. Bug fixes and break sites. API<br>Changes can break sites. Major architecture changes WILL break sites. Only<br>one of these version numbers is guaranteed to break crap when it changes.
<br>But ALL of them are capable of breaking stuff. That's what version release<br>notes are for (you do read them before upgrading right?). So the version<br>number is largely semantic anyways - it merely indicates a risk level, but
<br>the risk is always there anyways, and you should be doing the legwork before<br>installing, or reading the associated post with the release, or reading at a<br>minimum the release docs in the package, all of which cover the information
<br>(in more depth) contained in the release number _anyways_ so what is the<br>point here?<br><br>I think Adrian's system here makes tons of sense.<br><br>But I don't think there is any value in changing release numbers - from a
<br>material, site management point of view all of the information needed to<br>upgrade should be in the release notes, including errata and potential site<br>breaking bits. If anything, we should be harping on making better (more
<br>consistent, more readable) release notes, not changing version numbers that<br>have been consistent for three years. It's a mere mental game imho. And<br>changing it would actually denigrate the stability and clarity of three
<br>years of release management - where is the sense in that?!<br><br>Jonathan<br><br><br></blockquote></div><br>