(If you're already familiar with this debate and the various proposals, you can skip to the table of pros and cons at the bottom of this post).
Motivation
Drupal core releases are currently numbered “X.Y.Z”, where “X.Y” correspond to a major revision, and “Z” corresponds to a patch level. We assign no special significance to “Y”, and stable releases are not guaranteed to be (and in fact, never are) compatible with each other.
Whenever a major revision becomes stable enough to release, we enter a new period of development in the TRUNK of the CVS repository. During this time, we have no way to identify the next release. Currently, we call it “cvs”, “HEAD”, or even “the next release”.
All of these names have the terrible property that the code which eventually became 4.6.0 was called the "cvs" code at one point in time, as was the code that became 4.7.0, as is the code that's now on the way to be 5.0.0. If you read an older issue, forum post, email, etc, that talks about the "cvs" version, unless you've got an incredible memory and can map the dates (if there’s a date at all) to the eventually released versions, you have no idea what code they're actually talking about.
This naming/numbering scheme causes real-life problems for the Drupal community. Developers have trouble referring to specific code. Bug reports against the code in the CVS TRUNK are ambiguously identified. There are currently 2146 issues marked for "cvs" -- how many should be considered before we freeze/release the next stable release? We have no idea. Documentation can’t be written in preparation for the next release, since the version number has not yet been finalized. During the development cycle, there’s no way to identify the state of the core source in a way that contributed modules could test if a given change to the API will solve the problem or provide the feature that caused it.
Option #1: Stable and development releases for core
Core version numbers would retain the same basic form: Major.Minor.Patch. However, we would now provide official releases of both stable and development versions of Drupal. Stable releases always have a minor version number that is even, whereas development releases would always have a minor version number that is odd. The whole world is familiar with this numbering scheme thanks to the Linux kernel (and various other projects) doing it this way for over 10 years.
How development releases would work
Once the X.Y.Z stable release goes public (Y must be even), the code in the CVS TRUNK would immediately become X.(Y+1).0-dev. The following stable release could be either (X+1).0.Z, or X.(Y+2).Z. Dries can decide this once the development series has reached code freeze, we know exactly what changes and new features are in, and whether they justify a new major release (which would remain an entirely subjective decision).
We'd make no claims that different patch level releases in the same development series would have the same API or be compatible with each other in any way. We would retain the right to break the database upgrade path across development releases (just like we do for code in the TRUNK today) and only guarantee a stable, flawless upgrade path between stable releases of core. We would never promote a development release on the front page of drupal.org, nor in the download pages. Development releases would basically just be visible as tags in the CVS repository, as possible options for filing issues against, and potentially off a special page for downloading tarballs that was clearly marked with big, scary language about how unstable the code is.
Example with stable and development releases
Once the DRUPAL-5-0 branch is created for core and we enter the 5.0.0-(BETA|RC) period, the CVS TRUNK immediately becomes 5.1.0-dev. Whenever we want, we release 5.1.0, but make it clear to everyone that it is not stable, since the 2nd digit is an odd number.
After N months of code "thaw" are done, 5.1.5 is out, and we decide it has all the API changes and new features we want. At this point, Dries decides if the next stable release deserves to be 6.0.0, or 5.2.0. He decides it's just going to be 5.2.0. We make the DRUPAL-5-2 branch and change its version string from 5.1.6-dev to 5.2.0-beta-1. The TRUNK immediately becomes 5.3.0-dev. We start making 5.2.0-BETA-N releases. Eventually, we're ready to make 5.2.0-RC-N release candidates. Finally, we officially release 5.2.0 to the world.
Option #2: two-digit version numbers
Since the middle digit currently has no special meaning, and since core releases are never compatible with each other, why bother? As soon as the DRUPAL-X branch is created and the X.0 release goes into beta, release candidates, and finally the official X.0 release, the TRUNK would immediately become (X+1).0-dev. We’d always know what the next release is going to be called. In fact, we'd even be able to refer to something 2 releases away, if we had to (e.g. "we're not going to be able to commit the whole new Data API patch for 6.0, it'll probably have to wait for 7.0...").
Example with 2 digit versions
Once the code is frozen, we'll make the DRUPAL-5 branch. The version string on the TRUNK will immediately become 6.0-dev. After some beta and release candidates, when the code is finally stable, we'll ship version 5.0. Once there are important bugs fixed, or perhaps a security hole we close, we'll release version 5.1 from the DRUPAL-5 branch. further bug fix (patch-level) releases from the DRUPAL-5 branch will be 5.2, 5.3, etc. Meanwhile, API changes and new features will be added to the 6.0-dev version on the TRUNK. At some point, we'll freeze the code and make the DRUPAL-6 branch of core. The TRUNK's version will become 7.0-dev. We'll start making 6.0-beta-N and create some release candidates off the DRUPAL-6 branch, and eventually ship the 6.0 stable release.
What about code names?
Another possible solution to this problem is to introduce "code names" for Drupal core. For example, what Apple does with the cat names for the upcoming versions of MacOS ("Panther", "Jaguar", etc) before the names are mapped to a specific version number (so the next big cat might become MacOS 11.0 instead of 10.5). There was a big thread on the development list about this (which started here and was moved to its own thread). I've spoken to Dries at DrupalCon, and we're both opposed to code names for the following reasons:
- Requires an extra step (e.g. looking in a handbook page) to map names to numbers -- yes, lots of other projects have code names, but that doesn't make them easily usable
- Adds no value given these other alternatives that solve the same problem
- It complicates the issue queue if people submit issues against a code name in 1 instance, and version numbers in the other
Code names create too much hassle for no gain (given the alternatives). Dries is opposed. End of story. ;)
Pros and cons of remaining alternatives
In summary, and to aid the decision, I've created a table of the pros and cons of the 2 remaining solutions. One of these 2 options will be adopted after the community has a period to comment on them. If other pros/cons are raised as comments in this post, they will be added to the table. Please do not re-iterate pros or cons already listed.
Before the table, I'll list the pros and cons that are shared by both of the proposals.
Shared Pros
- Removes the need for ambiguous "cvs", "HEAD", or "TRUNK" terminology
- Avoids the complications and extra work to map code names to version numbers
- Saves us from the frivilous debate about what kind of codenames we should use
- Issues are always identified via numbers
- All digits in the version number have precise meaning
- Allows the core maintainers to tag and identify the state of the TRUNK at various important stages during the development of a new stable version (either via "5.1.X" or "6.0-dev-1" tags/releases), such as before and after major API changes.
Shared Cons
- Requires the entire drupal community (users and developers) learning a new system, which involves documentation and effort.
To be clear, Dries has already agreed that these pros outweigh the only con, so one of the new conventions will be adopted. Don't bother commenting or voting in favor of keeping things the way they are, or continuing to advocate for code names.
Table of unique pros and cons
| Stable/Devel Releases with 3-digit Numbers | 2-digit Version Numbers | |
| Pros |
|
|
| Cons |
|
|
Regardless of which option we choose, now is the perfect time to switch. Our next stable release will either be "5.0.0" (with a middle digit that's even) or "5.0" (since we've already decided to change the major version).
Have any other pros or cons? Add a comment below and I will fold them into this table as appropriate.
Thanks!
-Derek
Comments
Option #2 +1
I'm all for option #2. If we aren't going to have code names it seems like the simplest thing and it works well with our backwards compatiblility free development cycle.
I like #2
As a user, not a dev, #2 is much less confusing. I can see lots of people not realizing / remembering they can't use odd numbered releases regardless of how long linux has been doing it. :)
Michelle
--------------------------------------
My site: http://shellmultimedia.com
odd numbered releases would be hard to find
we'd make it exceptionally difficult for anyone to actually *find* an odd numbered release anywhere on drupal.org. they'd basically have to be using CVS and checking out from a tag to get one of these "releases". if you're clueful enough to do that much, you're clueful enough to understand option #1. ;) but, point taken... #2 is more simple.
___________________
3281d Consulting
+1 for 2-digit
It's more intuitive. Any release that revises/breaks the API gets a new number. Sub-releases get a new decimal.
From a marketing standpoint, it is a clearer representation of the rapid development Drupal undergoes.
Also, if we're going to do it, now's the time, with 5.0 impending. It would be much messier if we were in the middle of a point major release.
As for project names, used as nicknames they might help generate a little buzz, but also could theoretically cause confusion. Besides, what would the theme be? (If Apple uses cats [why?], would Drupal use ... water metaphors? Drupal Steam, Drupal Fog, Drupal Ice, Drupal Snow [Drupal Packed Powder?]....)
Laura
_____ ____ ___ __ _ _
design, snap, blog
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
2 digit system
I agree that even though developers may be quite familiar with the 3 digit system, end users will not be.
If I have version 5.0.8 installed and I find a reference to a 5.1,2, I'm going to go out of my way to find it and install it. Common wisdom (an oxymoron to be sure) says that newer versions are always better, so upgrade whenever possible.
Please don't ask me to remember the even/odd technicality. It's too much work when you're trying to run a site and do other things too.
While it may take the most effort to switch over to, it will save so much extra work in the future explaining the format to new users.
- Alan Tutt
http://www.PowerKeysPub.com
- Alan Tutt
Exceptional Personal Development for Exceptional People
http://www.PowerKeysPub.com
Option 2 more self-explanatory
Another factor, relating to the comparability with numbering used by other projects, is compatibility. For most 3-digit projects that I know of, a change in the major version is an implicit statement of "we're breaking the API, sucks to be you." A minor number change is a feature addition or refinement, but not a BC change. Example: KDE is API-compatible (mostly) for the entire 3.x series. KDE 2.x code, however, does not work on 3.x without major changes and 3.x code won't work on 4.x without major changes. PHP itself uses similar logic, although they use minor version numbers for minor breakage (eg, referencing handling changed very slightly to fix a security hole from 4.3.11 to 4.4.0), while major numbers indicate major changes (5.0.0).
Drupal has the "we're breaking the API, sucks to be you" policy on every version. I'm not disputing that or suggesting we change it, just observing. :-) Every version has breakage, since we really don't have a feature-addition-wth-BC cycle. Major API breakage, by convention, would be a major number change. That would argue with Option 2 as the more readily-self-explanatory system, as people are more likely to guess correctly that Drupal 7 code won't work with Drupal 8. So I guess that's a pro for #2, that it's more self-explanatory as far as module compatibility goes.
--
Larry Garfield
http://www.garfieldtech.com/blog
--
Larry Garfield
http://www.garfieldtech.com/
Thinking Functionally in PHP: https://leanpub.com/thinking-functionally-in-php
#2 cons
Some potential downsides of option #2:
- No way to distinguish the "size" of a change. Not every version change is a revolutionary change in the way the Drupal World works. That's what minor numbers are for. The 4.5->4.6 transition was before my time, but from what I've seen it was a much smaller change than 4.6->4.7. (Personally I think the 4.7->5.0 change is smaller, too, but that's beside the point. :-) ) Option #2 avoids the debate about "is this 5.2 or 6.0", but it also removes the ability to make use of that distinction between a "major" and "minor" set of changes.
- Reduced marketing impact. The masses have been trained to get more excited about a major number change than minor number change. If we start doing that every version, the impact lessens. Vis, "version inflation" can work against us marketing-wise. (This is a parallel to 3-digit pro #4.)
- x.0-syndrome. The masses, particularly PHBs, have also been trained (not always inaccurately) to view a .0 release as "experimental and buggy". Lots of new changes, so the bugs haven't been worked out yet, wait for SP1. If every new version is an x.0, it could also be seen as being "perpetually bleeding edge and unstable". Of course, the way Drupal works it could be argued that is more accurate. ;-) This one could be midigated by not calling it "Drupal 5.0" but simply "Drupal 5" (and then 3 weeks later here's Drupal 5.1 mumble mumble.)
I presume Drupal XP followed by Drupal Vista is out of the question? :-)
--
Larry Garfield
http://www.garfieldtech.com/blog
--
Larry Garfield
http://www.garfieldtech.com/
Thinking Functionally in PHP: https://leanpub.com/thinking-functionally-in-php
+1 for 2 digit system (option 2)
To reply to crell's extra potential downsides:
-The "size" of the change is not easy to tell from the way that Drupal releases now - as you actually pointed out. As long as the drupal drop continues moving the difference from each release in the 2 digit system will probably make sense since core compatibility between releases is always broken between releases.
- Releasing a new version every 6-months-to-a-year isn't a big deal for marketing or version inflation...These releases will be "big" (see above) in terms of breaking existing modules/code between releases.
- It's relatively true that the X.0 releases will be unstable, but if we look at 4.6 and 4.7, the X.1 release came within 2 months of the X.0 release: most site admins could wait 2 months before upgrading just to satisfy this requirement.
For me choosing between these choices, I like option #2 more than Option #1.
Also, big thanks to DWW for this work and please consider donating to his work udating the project module so that this system can see the light of day.
--
Growing Venture Solutions
Drupal Implementation and Support in Denver, CO
--
Morris Animal Foundation
x.0 unstable
I suppose it's also the case that by the .1 release we have a decent set of modules ported. The big and complicated ones (Views, CCK, Ecommerce, Location, etc.) could easily take that long anyway. So maybe the x.0-is-unable thing could be a pro. :-) I'll leave that to Dries/Derek to decide.
--
Larry Garfield
http://www.garfieldtech.com/blog
--
Larry Garfield
http://www.garfieldtech.com/
Thinking Functionally in PHP: https://leanpub.com/thinking-functionally-in-php
clarifications
- your first two points ("size" of change, and "marketing impact") are already covered by pro #4 for the 3-digit option.
- x.0 syndrom is totally unrelated. no matter what we do, we'll have a .0 release for every major "stable" core API that we freeze, and it'll probably have some bugs, and we'll release a .1 version days/weeks/months later. i'm not saying *every* release of core will be an X.0. just every *new* stable release with a whole new API (4.6.0, 4.7.0, etc). we'll always have to make patch-level changes, which fix bugs and plug holes, but don't break compatibility with modules and don't add new features.
- right, if we adopt #2, everyone has to get out of the habit of using 2-digits to refer to a "series" of drupal core. it's no longer "Drupal 5.0 lets you use JQuery and blah, blah, blah...". you have to start saying "Drupal 5..." or "Drupal version 5..." or something. 5.0 was just the initial release of the Drupal 5 series. this is pro #1 for the 3-digit option (continuity with 2-digits to refer to core compatibility).
i thought it'd be obvious, but maybe i need to explicitly fill in the inverses of each pro in the other option's cons and vice versa.
- re: "Drupal XP" -- which part of "Code names create too much hassle for no gain (given the alternatives). Dries is opposed. End of story. ;)" wasn't clear enough? ;) yes, completely out of the question. other posts that attempt to revive the codename proposal will probably just be unpublished, unless they offer new insights into the problem that haven't already been addressed. ;)
___________________
3281d Consulting
yes for #2
All the arguements are made above- and the odd/even thing is likely to cause endless confusion.
---
Work: BioRAFT
Option #2
--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ
...
You are missing a major con for both point. Major confusion over changing the scheme.
additional random points.
Option #2 has the illusion of simplicity at the price that simplicity brings. No flexibility for actual major changes. This leads to version number 'marketing' inflation. I am not one to actively market but even number major releases do have clout when appropriate. Please note the irc and email campaign to make 4.7.x be the 5.0.x and see the buzz we're getting as a result of waiting until the difference was apparent to the end users/site admins.
In your basic assumption I think you have something not quite right
You miss the point of the Y version information. If you look at the release history of Drupal, the basic UI interface, while updated at times, has not in fact changed substantially from Drupal 4.1 to Drupal 4.7. It was all using the same link organization to accomplish access to the tasks. Even the big admin UI re-org for 4.5 - 4.7 merely attempted to continue this logical path forward in the menu. 5.0 actually changes the link you see at /admin. It changes the theory of organization to tasks based. With the x.y.z it is possible to see major the major leaps within Drupal versioning. version 3.x.y to 4.y.z to 5.y.z
The Linux community does in fact use the even/odd dev release scheme. This leads to interesting forum/support questions in that community last I looked where an amazing number of people were using the dev release lines on live servers and the live branch ended up pruning said functionality. Thier audience is also advanced technical users.
I suspect that adding a 'dedicated' dev branch per release with odd numbers will increase the amount of questions/panic/complaints in the our forums regarding use of the odd number releases in the forums. I could be wrong but we have already started seeing people asking about live site with 5.0 in the forums. While it is unlikely to have such an extended dev release as did 4.7, it is also possible to happen again in the future.
However, if you do have to go with one or the other then #1
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
missing?
compare:
@sepeck: You are missing a major con for both point. Major confusion over changing the scheme.
vs. @original post: Shared Cons 1. Requires the entire drupal community (users and developers) learning a new system, which involves documentation and effort.
fighting that confusion and resistance to change (via documentation and lots of effort) is exactly what i'm talking about...
otherwise, yes, #2 is more simple at the price of less flexibility about the "major" releases (as explained in the post and in the table). i don't miss the point of our existing "Y" version numbers -- it's "smaller" changes -- but they still break all compatibility in contrib and sites have to be upgraded via lots of porting/effort if they need the latest features.
my point is that there's no objective, quantifiable thing that changes if it's X.(Y+1).0 vs. (X+1).0.0. it's just a subjective, "it feels like a major release". there's no X == API, Y == feature set, Z == patch level or anything like that. it's currently X == really big, Y == still big enough to break everything about your site, Z == security/bug fix. this feeling of "really big" is the "potential for marketing/PR" i put as pro #4 of the 3-digit approach, coupled with the pro #3 about versions not climbing "too fast".
i fail to see what i'm missing. ;) maybe i just wasn't clear enough...
___________________
3281d Consulting
Option #1
I vote option #1, because it's what I'm used to in gnome and linux and such. You could easily mark beside each developmental release the fact that it was developmental. I don't even think you'd have to train people to use it if it's clearly marked on drupal.org. If anyone gets on CVS, they're going to know what's going on most likely anyways.
--
Bradlis7.com | Churchofchristnet
Let me add one shared con,
Let me add one shared con, and one, related question:
Shared con: Neither system has any inherant mnemonic value that indicates whether or not a given version is a development release, bug fix release, or feature release. That is, you can't just look at the version number and know what it is based only on experience outside of Drupal. Most people would think that the difference between 5.1.2 and 5.2.0 is that the latter has added new features, while the former is a release that's been out for a while and has a couple of teensy patches or security fixes. They'd also think that upgrading from 5.0 to 6.0 is just as big a problem as upgrading from 6.0 to 7.0, not to mention having major new features in each step, and they'd want to know if any new features appeared between 5.1 and 5.2.
Here's the question: What exactly is the difference between the version string and the version? For the first example, how is changing the version string from 5.1.6-dev to 5.2.0-beta-1 really different from changing it to 5.1.6-beta-1? Both choices indicate a switch from development release to beta release; neither has any more information than that. Or, for the second example, what's the difference between saying "CVS TRUNK immediately becomes 5.1.0-dev" (quoted from above) and saying "CVS TRUNK immediately becomes 5.1.0"?
The more I think about it, the more I think that neither the problem nor the solutions here are well-defined, so it's not at all clear what problem they're really solving (or if they're really solving it). If all that's needed is a way to indicate the next release with new functionality and/or API changes, then something like 4.7.next seems to be as good as any, and simpler than all the other suggestions.
Gary
#2
+1. Intuitive and simple. Let's implement it.
I can "counter-con" most of the cons people have raised about this issue.
1. Documentation will be needed: I don't see what documentation will need to be written to tell people "6.0 is newer than 5.0 and the two are not compatible" and believe we can probably in fact eliminate A LOT of documentation/support requests/other effort that's currently talking about the fact that 4.7 is not a "minor" update to 4.6 as some people expect, and is not backwards compatible in any way, shape, or form with the previous release.
2. #1 is the way Gnome/Linux do it: Gnome/Linux have a vastly different target audience than Drupal does, so I think we should keep with what's most intuitive for "mere mortals."
3. No way to determine "size" of a change between releases: Fair point. However, API-wise, 4.6 => 4.7 was MUCH more extensive than the change from 4.7 => 5.0. So one could argue that the current system doesn't really allow for that either, since we tend to base major releases on stuff the end user can actually perceive.
4. Marketing: I couldn't really care less. ;) But I actually don't see the big deal here. EVERY version of Drupal has brought forth major changes; aren't they all worth having buzz about them and showing off? I think it's true that people pay more attention to a 4.x => 5.0 change than a 4.6 => 4.7 change, which is gravely unfortunate considering all the advances made in 4.7, particularly around the extra flexibility it affords developers.
5. x.0 syndrome: I actually think that's just fine and not an irrational fear at all. Chances are, the vast majority of contrib modules won't be ported for x.0 anyway, and of course bugs will be found when non-developers start using the software in production sites. People might be encouraged to wait until x.1 to let some "gineau pigs" find the bugs for them.
6. No shared mneumonic value: As I understand it, under this system, as soon as 5.0 is released, we start 6.0-dev. Right there, is a mneumonic that says, "this is a development release, STAY AWAY" ;) As for features/bugs, we just retain our current status quo of no new features for stable releases, and mention in each release notice that 5.1 -> 5.12055 are all bugfix releases. Seems simple enough to me? Maybe I'm missing something though.
Go for option 2
As noted elsewhere:
* it's simple
* we break stuff every version, so saying it's compatible with the Drupal 5.x series makes sense/is easier
And, of course, thanks to Derek for all his hard work on this.
#2
I too think #2 is the better choice, and would like to point out that neither of the con's for #2 have to do with whether the scheme itself is a good idea. Both are simply related to some pain involved in the switch.
The second
I love simplicity. The second digits buys nothing and I do not fear version inflate at all.
Marketing value... somehow Ubuntu releases get their press with using a simple version scheme. Maybe because those worth writing about?
--
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.
Option #2 (X.Y) please...
Hi! I'd like to throw my hat into the ring for the second option (two numbers, rather than three). As long as we're going to continue breaking the API, it makes more sense to me.
Comments
Option #1 is problematic. It is not really obvious. Note that Linux has been on 2.x.x for the longest of time. There is no 3.x.x in sight so far, which makes the first number moot. Also note that this convention is now abandoned by Linus et al.
If I were to chose between the lesser of two evils, it would be #2, but I think we have an opportunity to solve an issue, and passing on it though.
Neither option solves the problem of giving Dries the freedom to name the next release any number, while not disturbing issue tracking and documentation.
For example, you say that Dries can decide what to call the next version (X+1).0.Z, or X.(Y+2).Z. This does not solve the problem of what "the next release" is. Documentation and issues still refer to a non existent version. This exact thing happened in the 4.7 cycle. Many wanted it to be 5.0 because of FAPI. However, Dries said : "too late, we already called it 4.7 for so long". We still have that issue with either proposal.
Also, if Dries is forced to name it .0. and not .(Y+2). by convention, then we have introduced a restriction that prevents a release that has so many features from being incremented.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
Why is #2 the lesser of two evils?
It seems as though it solves exactly the problems that you describe?
The upcoming release of Drupal is 5.0.
Bug fixes to Drupal 5.0 become 5.1, 5.2...
The next release of Drupal will be 6.0.
If I want to discuss Drupal 2 versions from now, I say "Drupal 7.0" and everyone knows what I'm talking about.
There's no need to stress about picking a version number. There will never again be a, "Too late. we already called it 4.7" discussion, because It's already known in advance what the next N versions of Drupal will be called.
Ahh ...
Your 3 lines managed to get it through my decaffienated brain.
So, the main point here is that new releases will always be X+1.0 no matter whether the features are major not not, and as long as there is breakage in the API.
Is there a possibility of releasing X.Y+1 as "the next release"? Or this will only be bug fixes and guaranteed to cause no API breakage?
The only drawback then for #2 is that X has the potential to be quite a large number (2 numbers per year , perhaps only 1). That is not a big issue for me personally, but some have a mental/psychological aversion to it.
#2 gets my +1 then.
Codenames are a stupid idea ... who ever came up with that ... ;-)
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
Is there a possibility of
The latter is my understanding. dww, please feel free to correct me if I'm wrong.
Yes, this is true. It means that if we keep our current rate of 2 releases per year, at the end of 2010, we'll be up to Drupal 13.0. And I guess that's something worth thinking about, but to me the confusion it alleviates is worth whatever mental/psychological trauma one might get from the thought of a Drupal 13.0 in 4 years. On the other side of the mental/psychological scale, it'll put more pressure on we developers to make sure that each version is that much more kick ass than the one before it since they're all major releases. ;)
What's wrong with Drupal 13.0?
What's the problem with Drupal 13.0? I mean, Windows was up to 2000 before they switched to code names (and server is at 2003!).
:-)
Release numbers vs version numbers
AutoCAD used to use incremental release numbers before switching to the MS style year names. I think they got up to R14 before the switch. It wasn't a problem for the users at the time.
I suspect up to three digits is ok in a version number for users to easily keep track of. Drupal 5.8.2 and Drupal 13.2 are both the same number of digits, so with option #2 we should be ok until 2060 or so ;)
--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ
Build numbers?
Another option would be to use build numbers for internal builds, and version numbers for suitable-for-production releases. That would allow you to still use the common major.minor.bugfix versioning, while having another system for identifying cvs builds. It would also prevent getting cvs builds confused with releases.
You could either do:
"Drupal-cvs build 5000" for the 5.0 cvs builds then increment the last 2 digits of the build number however you wish.
or
"Drupal-5.0-cvs build 0100" and maybe increment to 1000 for 5.0.1 builds.
Or any other method of incrementing the build numbers you wish. But the advantages would be it would be independent of public versioning, could be understandable to developers, and would be unlikely to confuse users into downloading a cvs build.
In that scenario, major and minor releases would still have unique meanings. Major would be major features that affect all of Drupal, breaking the API. Minor could be minor features, that may break parts of the API. And bugfix is just that, and will not break the API. Or looked at from the point of the user, major versions require relearning a few things. Minor, while they may have some significant changes, will mostly look and operate the same. And bugfixes would operate almost exactly the same, just perhaps more secure.
See Wikipedia: Version for that and other standard methods.
seems like #2 is the winner... ?
sounds like an overwhelmingly positive response on #2 -- when i spoke to dries in brussels, he was leaning that way, too.
webchick is correct -- option #2 would be X.Y, where X is the major revision (API/feature changes), Y is the patch level (only bug and security fixes). the difference between 5.0 and 5.1 would be similar to the difference between 4.7.0 and 4.7.1...
re: huge numbers in N years and marketing: not to denegrate the evangelists among us, but drupal basically markets itself. i get the sense that more and more people use it because it solves their problems and they hear great things about it, not because of what version number it is.
the 2 cons i listed are indeed just pain for the project module and our cvs repo for the switch... i guess everyone who votes for #2 should therefore donate to the new release system so i can deal with the internal complications the switch from 3 to 2 digits will cause. ;)
still waiting for the final word from dries before i plunge wholeheartedly into writing specific code to make this happen, but i'm already starting to think about and test solutions to some of the details. hopefully we can wrap this up soon and move on...
thanks everyone,
-derek
___________________
3281d Consulting
Go ahead
Hi Derek, it seems to be save to go ahead with #2. If it fails, we can always roll back to the current scheme. That said, #2 seems to be well worth a try and has my support! :)
..
I'll coordinate updating the version information page with Derek.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide