+1  I definitely think this will allow a faster progression of features without having to worry about the quite loose terms "stable" and "experimental".  I think this will really help free you up to go forward at a much more natural pace.

Chris

--
Chris Custine
FUSESource :: http://fusesource.com
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Directory Server :: http://directory.apache.org


On Tue, Aug 11, 2009 at 7:04 AM, Alex Karasulu <akarasulu@apache.org> wrote:
Not like we've had enough conversations that sucked up vast amounts of our time before on this topic.  However after a conversation with Emmanuel I think we might have to present another approach.

Current Scheme
----------------------

  o We have major.minor.micro numbers. 
      - major number denotes massive architectural shift
      - minor number denotes feature introductions
      - micro number denotes bug fixes and optimizations without changes to interfaces, db formats etc
  o Minor numbers were either 0 or 5.  The 5 was for experimental branches with many big features being added across different releases in the branch.  The 0 was for stable branches where no new features were being added but only fixes and optimizations were made.
  o The 0 or 5 schema came from the even/odd schema used in the older linux versioning scheme for the kernels before 2.6.  We switched to 0/5 because we wanted the move from 1.0 to 1.5 to mean more than a number change but to represent the shift in JDK compatibilities.  1.5 will only run on JDK 1.5 and up.

There's some good things about this schema and some bad things.

1. The scheme used takes a long time to bring about a minor release with "stable" feature additions.
2. Many of our 1.5 releases though were more stable than our 1.0 so this connotation was no longer working for us.
3.  The scheme was slowing us down but hopefully (not that we could measure it) was leading to a more stable LDAP server.  Not like we were building a desktop app that can get restarted to clear out leaks and such.
4. The scheme is just strange.  Going from 1.0 -> 1.5 then to 2.0 is odd.  What do we do go to 2.5 next?
5. What about nice little features that did not take time to do but must wait for other major features to be deemed 'stable' and usable?  They don't get to the user fast enough.

I'm sure lots more can be found for and against this model.  But at this point with the 0/5 stuff is just odd lookin and hard to make sense of.  After a convo with Emm on IRC we came up with the following new scheme:

Future Scheme
--------------------

  o We have major.minor.micro numbers: 
      - major number denotes massive architectural shift
      - minor number denotes feature introductions
      - micro number denotes bug fixes and optimizations without changes to interfaces, db formats etc
  o We bump up minor numbers whenever we add a new feature no matter how many new things were added.
  o We bump up micro numbers in case we make a bug fix or improvement.

The idea here is to just keep bumping organically as we like.  We can for example just go to 2.0.0-rc1 after 1.5.5.  This seems like a natural progression to get us out of this old scheme with one last .5 increment.  Then we can just keep bumping as we add feature after feature without the requirement for micro bug fix releases.  So we can have a 2.1.0 then a 2.1.1 etc or just jump to 2.2.0 from 2.1.0.  Up to us.  This is the cool thang about it.

With this freedom comes benefits to our users.  They get to see features faster since we do more releases back to back.  Hopefully though greater bug introduction will not be there.  But this is a balanced risk we will have to take. So our releases will sort of be like what Atlassian does for example for JIRA and Confluence.

Thoughts?

--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org