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<[email protected]> > 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 <[email protected]> > > -- ------------------------------------------------------------------------ Anthony Molinaro <[email protected]>
