+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 <[email protected]> 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 > >
