After a lengthy debate, the core Drupal system is moving to a new, more simple convention for its version numbers: there will only be 2 digits. For example, the forthcoming stable release will be version 5.0. The 5 represents the major revision of Drupal, and indicates what modules and themes will be compatible with it. The 0 is the patch level, and indicates that it will be the first release of this version of Drupal. Subsequent bug fixes and security patches will be released as 5.1, 5.2, and so on. New features will only be added to the next version of Drupal core, (the 6.0 release in this case). You can find out more about this topic by reading version numbers, policies and which version you should use.

The naming convention for the CVS branches used for core and contributions has also shifted to match this new numbering scheme. Previously, the 4.7.x series of Drupal core lived on the DRUPAL-4-7 branch. Now, once the code moves into the final stages of preparation for the stable release, there will be a DRUPAL-5 branch where the 5.x series will live. Modules, themes and translations that have been ported to this version of core will have a DRUPAL-5 branch, as well. More information about Drupal's use of CVS can be found at the handbook pages about CVS.

Comments

bertboerland’s picture

okay, it will take some time before all of us (well, in each case me) will be used to the new version system, but
Removes the need for ambiguous "cvs", "HEAD", or "TRUNK" terminology
is such a big pro, that I am fine with this new system.

In the end, it are just numbers and not /that/ important unless we want to get in the version numbering contest... which we dont.
--
groets
bertb

--
groets
bert boerland

xmacinfo’s picture

When something works well, why fix it?

Is the goal to release major revision version 9 or 18 before the end of 2007 or is the goal to ship the best version of Drupal? Will Drupal 16.4 (2-digit versioning) be a lot better than Drupal 6.3.2 (current 3-digit versioning)?

In the end, using any 2- or 3-digit versioning convention won't make any difference. Users and developers will adjust quickly. However, I fear that each major releases will have a lot less new features.

chx’s picture

This actually have a lots of pros and aside from the need to re-learn stuff little cons.

For example, now there is no question whether we will release 5.1.0 or 6.0.0 first half of next year -- we will release 6.0 and that's it. This does matter but really read the debate linked by dww.
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | please donate

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

dww’s picture

When something works well, why fix it?

because it didn't work at all. read the debate: http://drupal.org/node/85943

is the goal to ship the best version of Drupal?

yes.

However, I fear that each major releases will have a lot less new features.

as always, that solely depends on the drupal development community to keep adding new features whenever there's a "code thaw" and development opens up on the next version. this is ENTIRELY unchanged by the new system.

the only real difference is that we never have to use the totally inaccurate, ambiguous, and annoying terms "cvs", "HEAD", "TRUNK", "next release" when talking about the next version (since we'll always know exactly what it will be called), and we never have to have a philosophical debate about if the changes between 4.6.x and 4.7.x were big enough that 4.7.x really should have been called 5.0.x, instead.

again, read the discussion that led to the change, before you criticize something you don't really understand.

thanks,
-derek

___________________
3281d Consulting

Robardi56’s picture

On the contrary, I guess each new major release will have much more features.... but I fear more delay between each major release.

Brakkar

Cool_Goose’s picture

Well it was almost an year for 4.7 afaik so it can't get any worse i think :P
------------------------------------------------------
Be Smart, Think Free, Choose OpenSource.

benthere’s picture

Yeah I don't really understand how dropping the minor version releases solves the problem of not ambiguously labeling everything "cvs", or how it solves the problem of users downloading cvs versions. In both cases, branching "4.7.0" or "5.0.0-dev" or "5.1.0-dev" satisfy both of those problems just as well as "5.0-dev" does.

It solves the problem of what the next version number will be, but IMHO that would be better solved by planning scope beforehand. On the other hand, I guess if you have long, really long iterations, then everything actually is a major release. In that case, it would make sense to only need major version numbers and bugfixes. I can't really say whether a long-iteration development process is best for Drupal or not, but at the same time, I haven't seen it discussed, either.

If there are other reasons, feel free to let me know what they are. But I didn't understand it in that other thread. To me, it's just dropping the ability to release minor versions. Whether a release is major or not, it will be released with a major version number. That may have implications in a user's decision of whether or not to upgrade, how they understand the significance of a release, their expectations in a release, etc.

Robardi56’s picture

I have no problem with 2 digits versioning..... but usually, from my experience with other scripts, developers like to make "enhanced" intermediate releases with minor new features in between major releases. From reading the post no new features will be added in intermediate releases with 2 digits.

I think it all depends on the amount of features developers will estimate enough from moving to a version to another now. Will this mean 1 major release a year ? 2 releases a year seems a good goal to keep with drupal adapting to web development trend.

What about setting fixed dates for major releases versions ? With such a huge community (and growing) there will always be enough features added during 6 months for a major release and knowing when are the releases occuring will help webmasters plan ahead. 3 months new features, 3 months code freeze / bug fixing seems a good rythme compromise and would make good use of 2 digit versioning.

What are you thinking about those 6 months fixed cycles ?

Brakkar

dww’s picture

there's so much confusion because even though drupal used 3 digits in the past, it never meant it. there never was a "minor" release of drupal core that only added a new features. every stable release of core has broken module/theme compatibility, changed the internal APIs, and added new features.

the new numbering scheme just acknowledges this fact to simplify things. many, many people were confused about 4.6.x vs. 4.7.x, thinking that their 4.6.x modules might work with 4.7.x since "it's only a minor release, how bad could it be?", when in fact 4.7.x required a fundamental re-write of nearly every contrib module...

again, the timing of releases, how many features get added or not, is completely unchanged by this system. yes, the current plan was and is to aim for 2 stable releases a year, with roughly 3 months code "thaw" and 3 months of code "freeze", hardening, testing, etc. that might change at some point, but not because of the new numbering scheme.

finally, (hopefully for the last time) i'll explain why this solves the evils of the "cvs" version. before, we couldn't call the next version by the number it was going to become, since there was this unknown factor for if dries felt like the changes in a release were fundamental enough to be a "fundamental, really" major release, or just a "normal, enough to break everything about your site" major release. so, we couldn't call it "4.8.0-dev", since it might have turned into "5.0.0-dev" (which it did). now, once we branch the core for the 5.x stable series, we immediately know the trunk will become the 6.x series, and instead of marking issues, writing emails, etc that refer to "HEAD" or "CVS", we can just call it what it is: "6.0-dev". same goes for what the nightly snapshot tarballs will be named.

clear enough? ;)
-derek

___________________
3281d Consulting

Robardi56’s picture


there's so much confusion because even though drupal used 3 digits in the past, it never meant it. there never was a "minor" release of drupal core that only added a new features. every stable release of core has broken module/theme compatibility, changed the internal APIs, and added new features.

Indeed, you are right, there was no real "minor" drupal release... so I guess cycle will be unchanged or at least not slowed.

++ For the two digits.
I see really no problem in drupal getting to version 5,6....12,14 or any high number.

Brakkar

benthere’s picture

Thanks for explaining that clearly, Derek. I guess my confusion came about because I've never looked at major/minor versioning in terms of whether it breaks the API. For example, when developing extensions for Firefox, the compatibility-checking code generally assumes minor versions will be incompatible, so an updated extension would need to be released even if it just changed the maxVersion from 1.0 to 1.5. But maybe I'm just too used to open source programs breaking their API frequently. ;)

Anyway, if Drupal 5.0 includes CCK or other major improvements, it will certainly be a 5.0. But I don't know if 4.5, 4.6, or 4.7 should have been 5.0, at least from a blog/forum/cms administrator's perspective, ignoring changes to API.

Though it makes sense when explained that major versions should be released anytime the API breaks, which apparently has been/will be every time. Thanks.

-Ben

dww’s picture

-derek

___________________
3281d Consulting

Wolfflow’s picture

Please allow me, even as a older newby, that I am sure that the spread over of Drupal will never stop and if you consider the equation:

  • more_user = more_new_test
  • more_new_test = more_new_idea
  • more_new_idea = more_new_features
  • result = X = Always the Best Open Source CMS =
  • Drupal

    I'm completely in agreement with samplifying the nomenclature that refer to Patches and Versions
    and all NewBy will profit a lot on that !!!

    Cheers

    Drupal User with some test Drupal show cases:
    http://www.adaccs.at/test/ Link to a DRUPAL 5 Beta 1 Showcase Site

    Contact me for drupal projects in English, German, Italian, Drupal Hosting Support.