On 21/09/06, Derek Wright <drupal@dwwright.net> wrote:
here's another option to consider, which has the following benefits:
a) no need for early binding of release numbers b) no ambiguity c) no code names
Although I prefer codenames I'm inclined to vote for the moving to release numbers option eg version.patch instead of the current major.minor.patch method. 1) there is no guaranteed API compatibility between minor releases anyway, so the distinction between major and minor releases doesn't mean as much with Drupal. We also seem to introduce major rearchitectural work in either minor releases or in stages over various releases making it difficult to pin down what a major release actually is. 2) The next release number is always predictable eg current+1. You can even refer to releases after that as well for changes that won't make it into the next release. 3) It won't generate the same resistance as codenames do. eg developers get a predictable name for the next version, but it is even simpler than the current situation and should avoid any potential newbie confusion. The only real downside would be once the release numbers got high enough, mentally distinguishing between release numbers might get harder. But that would probably be at least 10-20yrs away at our current release rate :) And we could still switch back to major.minor.patch again in the future if circumstances require it. -- Cheers Anton (aka styro)