Forgot your password?
New user?
Document Actions
#114: New version numbering policy for Plone the product
- Contents
- Proposed by
- Alexander Limi
- Proposal type
- Process
- Assigned to release
- State
- completed
Motivation
Whether we like it or not, Plone is in the product space, not the framework space — and should have version numbering to reflect that.
When an 18 month release cycle results in a .1 release, people perceive it as moving slowly, which was very clearly exemplified with the 2.1 release. Even though Plone 2.1 is a massive improvement over 2.0, there was almost no media coverage.
Another problem is managing perceptions on the upgrade front. When people upgrade from 2.0 to 2.1, they think it's going to be a very simple upgrade, and are surprised when third-party products need to be updated, their customizations need to be updated etc.
Assumptions
Other versioning schemes that have been evaluated but kept out of this proposal in the interest of not causing too much of a change from the current versioning policy are:
- The Plone 2005, 2006 scheme, which easily shows people the age of their instance, much like a car year model.
- Reserving the mythical Plone 3 to coincide with the Zope 3 "port". We'll be running out of pi digits by then. :]
- Naming the infrastructure change releases dot-zero. While I understand (and appreciate) the policy of doing this for frameworks to indicate compatibility, we're not in the framework space.
Proposal
My suggestion is:
- Be strict on keeping the 6-month release schedule plans
- Increment the version number by .5 on each of these releases
- Keep the traditional 2.5.1, 2.5.2 version numbering for maintenance releases (although personally I prefer the more common product-centric 2.51, 2.52 numbering, but I've been shot down on that earlier ;)
This will let us have one major (3.0, 4.0) release every 12 months, and a 3.5, 4.5 release in the meantime — with maintenance releases inbetween.
Implementation
I believe the easiest thing to do at this point is to keep the version number 2.2 for the next release, which is an infrastructure-focused release. Then, for the next release after that, we go for a 2.5 or 3.0 version number.
Version 2.5 would be the most logical step, but if we're going to — informally, at least — alternate the focus every other release between being UI-focused (front-end changes) and infrastructure focused (back-end focused), we should call the next release after that the Plone 3.0 release.
The reasoning behind this is that dot-zero releases get the majority of the press, and what people are interested in (from the reviewer front) is the UI, not the infrastructure.
If people think that the perception of going from 2.2 to 3.0 is not good, we should rename the 2.2 release to 2.5.
The changes look good
I agree with everything here although I'm glad limi's idea of "although personally I prefer the more common product-centric 2.51, 2.52 numbering" didn't make the cut :)
I recall seeing Netscape 4.7 and then 4.71 and thinking there must be some huge improvments to go from four-dot-seven to four-dot-seventy-one.
In my mind once you get to version 2.5.9 if you truly need a 2.5.10, something has gone wrong (ie taken too long for another major release to come out, etc)
3rd Party Product Versions
Has anyone, anywhere, invented a version numbering system that plays nice with its 3rd party developers?
Move to 2.5 directly
In my opinion we should move directly to 2.5 as the next version instead of calling it 2.2 for a number of reasons:
2.5 as in Zope 2 + Fiveslogan targetted at developers - following the.0 means UImeme otherwise the gap between 2.2 and 3.0 would be too broad, setting expectations too high+1 on the whole idea