directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <seelm...@apache.org>
Subject Re: [ApacheDS] How about yet another versioning scheme conversation gang?
Date Tue, 11 Aug 2009 13:19:28 GMT
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
> 


Mime
View raw message