Hi Alex, really +1 for your proposal.
Additional I think milestone release could also make sense. Kind Regards, Stefan Alex Karasulu 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 >
