incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Molinaro <antho...@alumni.caltech.edu>
Subject Re: Cassandra version number policy
Date Wed, 01 Jul 2009 22:22:42 GMT
Really?  Seems odd, but I guess conserves MAJOR version numbers (and explains
why I see so few open source projects with version numbers >1).

Whenever I've employeed this strategy within company borders I've simply
increased the MAJOR anytime there was a binary incompatible change.  Meant
I had a few packages with MAJOR version in the 20s, but kept the meaning
of the different versions clear.

Guess I'll wait for a commiter to weigh in, so we can find out what cassandra's
policy is.

-Anthony

On Wed, Jul 01, 2009 at 01:38:14PM -0700, Ryan King wrote:
> Typically in such strategies, minor releases before 1.0 can break
> back-compat, I assume (being a new lurker myself) that this would be
> the case here as well.
> 
> -ryan
> 
> On Wed, Jul 1, 2009 at 11:14 AM, Anthony Molinaro<anthonym@pinkbunny.net> wrote:
> > Hi,
> >
> >  I've been lurking on this list for a little bit and notice that you've
> > talked about a change to the on disk data format which would be incompatible
> > with prior versions.
> >
> > Will that change be a major version bump (ie, will it be 1.0.0)? If not what
> > is the policy regarding versions for cassandra?
> >
> > I'm used to the MAJOR.MINOR.RELEASE versioning where
> >
> > MAJOR is a binary incompatible change
> > MINOR is new functionality added
> > RELEASE is for bug fixes without new functionality
> >
> > Does cassandra follow this or some other strategy?
> >
> > -Anthony
> >
> > --
> > ------------------------------------------------------------------------
> > Anthony Molinaro                           <anthonym@alumni.caltech.edu>
> >

-- 
------------------------------------------------------------------------
Anthony Molinaro                           <anthonym@alumni.caltech.edu>

Mime
View raw message