Re: [ApacheDS] How about yet another versioning scheme conversation gang?

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

+1 for the "future scheme" as it's the same we're using for Studio. ;)
After 14 releases of Studio using the scheme, I have to say it's my
favorite...

Regards,
Pierre-Arnaud


On Tue, Aug 11, 2009 at 3:04 PM, Alex Karasulu <ak...@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
>
>