directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse McConnell <jesse.mcconn...@gmail.com>
Subject Re: [ApacheDS] How about yet another versioning scheme conversation gang?
Date Tue, 11 Aug 2009 13:20:04 GMT
>  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

Why not just adopt the convention that people most commonly associate
with x.y.z?

X - breaks API, no assurance that you can use out of the box
Y - features api alteration but basic assurance of api compat
Z - bug fixes and maintenance releases

I don't see a need to do anything else unless your dealing with some
requirement being forced on you

fwiw your new one is far more inline with that basic idea and is much
better then your previous one dealing with .0 and .5 and that
confusion...

cheers!
jesse

--
jesse mcconnell
jesse.mcconnell@gmail.com



On Tue, Aug 11, 2009 at 08:04, 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
>
>

Mime
View raw message