You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Anthony Molinaro <an...@pinkbunny.net> on 2009/07/01 20:14:28 UTC
Cassandra version number policy
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 <an...@alumni.caltech.edu>
Re: Cassandra version number policy
Posted by Anthony Molinaro <an...@alumni.caltech.edu>.
Right, I see you say 0.4.0 will be along soon after so people shouldn't
use 0.3.0 for anything serious, so I guess the question is how soon is soon
after?
-Anthony
On Sat, Jul 04, 2009 at 12:23:36AM -0500, Jonathan Ellis wrote:
> see the thread about the future of 0.3
>
> On Fri, Jul 3, 2009 at 11:24 PM, Anthony
> Molinaro<an...@alumni.caltech.edu> wrote:
> >
> > On Thu, Jul 02, 2009 at 06:28:39PM -0500, Jonathan Ellis wrote:
> >> > A somewhat related question, I'm using an svn external to keep a tree
> >> > in my svn project which builds rpms and maven packages. I currently have
> >> > that tree pointed at the HEAD, but that seems risky because its a moving
> >> > target. I'd like to point at the 0.3.0 release. Does the cassandra-0.3.0-rc3
> >> > tag represent that release? (ie, if I were to download the tarball and
> >> > checkout that tag would the code be equivalent)
> >>
> >> Yes, the rc3 tag is what will be released as -final, modulo some yak
> >> shaving (http://mail-archives.apache.org/mod_mbox/incubator-general/200907.mbox/%3C71e1b5740907020449m3f48cbd8o1b3f9c03ba6c144c@mail.gmail.com%3E).
> >> The code will be the same.
> >
> > Oh, I just noticed 0.3 does not include the nodeprobe script, would that be
> > hard to backport? I really like the idea of not having to poke holes to get
> > at the web server on my cassandra nodes.
> >
> > -Anthony
> >
> > --
> > ------------------------------------------------------------------------
> > Anthony Molinaro <an...@alumni.caltech.edu>
> >
--
------------------------------------------------------------------------
Anthony Molinaro <an...@alumni.caltech.edu>
Re: Cassandra version number policy
Posted by Jonathan Ellis <jb...@gmail.com>.
see the thread about the future of 0.3
On Fri, Jul 3, 2009 at 11:24 PM, Anthony
Molinaro<an...@alumni.caltech.edu> wrote:
>
> On Thu, Jul 02, 2009 at 06:28:39PM -0500, Jonathan Ellis wrote:
>> > A somewhat related question, I'm using an svn external to keep a tree
>> > in my svn project which builds rpms and maven packages. I currently have
>> > that tree pointed at the HEAD, but that seems risky because its a moving
>> > target. I'd like to point at the 0.3.0 release. Does the cassandra-0.3.0-rc3
>> > tag represent that release? (ie, if I were to download the tarball and
>> > checkout that tag would the code be equivalent)
>>
>> Yes, the rc3 tag is what will be released as -final, modulo some yak
>> shaving (http://mail-archives.apache.org/mod_mbox/incubator-general/200907.mbox/%3C71e1b5740907020449m3f48cbd8o1b3f9c03ba6c144c@mail.gmail.com%3E).
>> The code will be the same.
>
> Oh, I just noticed 0.3 does not include the nodeprobe script, would that be
> hard to backport? I really like the idea of not having to poke holes to get
> at the web server on my cassandra nodes.
>
> -Anthony
>
> --
> ------------------------------------------------------------------------
> Anthony Molinaro <an...@alumni.caltech.edu>
>
Re: Cassandra version number policy
Posted by Anthony Molinaro <an...@alumni.caltech.edu>.
On Thu, Jul 02, 2009 at 06:28:39PM -0500, Jonathan Ellis wrote:
> > A somewhat related question, I'm using an svn external to keep a tree
> > in my svn project which builds rpms and maven packages. I currently have
> > that tree pointed at the HEAD, but that seems risky because its a moving
> > target. I'd like to point at the 0.3.0 release. Does the cassandra-0.3.0-rc3
> > tag represent that release? (ie, if I were to download the tarball and
> > checkout that tag would the code be equivalent)
>
> Yes, the rc3 tag is what will be released as -final, modulo some yak
> shaving (http://mail-archives.apache.org/mod_mbox/incubator-general/200907.mbox/%3C71e1b5740907020449m3f48cbd8o1b3f9c03ba6c144c@mail.gmail.com%3E).
> The code will be the same.
Oh, I just noticed 0.3 does not include the nodeprobe script, would that be
hard to backport? I really like the idea of not having to poke holes to get
at the web server on my cassandra nodes.
-Anthony
--
------------------------------------------------------------------------
Anthony Molinaro <an...@alumni.caltech.edu>
Re: Cassandra version number policy
Posted by Jonathan Ellis <jb...@gmail.com>.
On Thu, Jul 2, 2009 at 1:37 PM, Anthony
Molinaro<an...@alumni.caltech.edu> wrote:
> So does that mean the versioning policy is
>
> UNUSED.MAJOR.MINOR
>
> where UNUSED is well, unused or some other marker, and a change to MAJOR
> means binary incompatibility, and a change to MINOR is new features or
> bug fixes which do not mean binary incompatibility?
I would say that MAJOR allows the possibility of binary
incompatibility, and we will mention this in CHANGES.txt and release
announcements if it does, but for the vast majority of future major
releases this will not be the case. Log structured merge just isn't
that complicated a format.
> A somewhat related question, I'm using an svn external to keep a tree
> in my svn project which builds rpms and maven packages. I currently have
> that tree pointed at the HEAD, but that seems risky because its a moving
> target. I'd like to point at the 0.3.0 release. Does the cassandra-0.3.0-rc3
> tag represent that release? (ie, if I were to download the tarball and
> checkout that tag would the code be equivalent)
Yes, the rc3 tag is what will be released as -final, modulo some yak
shaving (http://mail-archives.apache.org/mod_mbox/incubator-general/200907.mbox/%3C71e1b5740907020449m3f48cbd8o1b3f9c03ba6c144c@mail.gmail.com%3E).
The code will be the same.
-Jonathan
Re: Cassandra version number policy
Posted by Anthony Molinaro <an...@alumni.caltech.edu>.
So does that mean the versioning policy is
UNUSED.MAJOR.MINOR
where UNUSED is well, unused or some other marker, and a change to MAJOR
means binary incompatibility, and a change to MINOR is new features or
bug fixes which do not mean binary incompatibility?
Just want to get a sense of when I should be worried about an upgrade
(I know talking about upgrades is probably fairly silly based on the fact
there has only been one release, but still I like to plan ahead).
A somewhat related question, I'm using an svn external to keep a tree
in my svn project which builds rpms and maven packages. I currently have
that tree pointed at the HEAD, but that seems risky because its a moving
target. I'd like to point at the 0.3.0 release. Does the cassandra-0.3.0-rc3
tag represent that release? (ie, if I were to download the tarball and
checkout that tag would the code be equivalent)
Thanks,
-Anthony
On Wed, Jul 01, 2009 at 05:34:11PM -0500, Jonathan Ellis wrote:
> We have already committed to breaking disk format for 0.4 (to fix OOM
> conditions). To me 0.3 to 0.4 is major (like with postgresql 8.3 to
> 8.4) but I guess it's just semantics.
>
> -Jonathan
>
> On Wed, Jul 1, 2009 at 1:14 PM, Anthony Molinaro<an...@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 <an...@alumni.caltech.edu>
> >
--
------------------------------------------------------------------------
Anthony Molinaro <an...@alumni.caltech.edu>
Re: Cassandra version number policy
Posted by Jonathan Ellis <jb...@gmail.com>.
We have already committed to breaking disk format for 0.4 (to fix OOM
conditions). To me 0.3 to 0.4 is major (like with postgresql 8.3 to
8.4) but I guess it's just semantics.
-Jonathan
On Wed, Jul 1, 2009 at 1:14 PM, Anthony Molinaro<an...@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 <an...@alumni.caltech.edu>
>
Re: Cassandra version number policy
Posted by Anthony Molinaro <an...@alumni.caltech.edu>.
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<an...@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 <an...@alumni.caltech.edu>
> >
--
------------------------------------------------------------------------
Anthony Molinaro <an...@alumni.caltech.edu>
Re: Cassandra version number policy
Posted by Ryan King <ry...@twitter.com>.
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<an...@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 <an...@alumni.caltech.edu>
>