Mailing-List: contact cassandra-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jbellis@gmail.com designates
 209.85.219.220 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:from:date:message-id:subject:to:content-type;
        b=FNvcY1sqCiAyaRFWD8fvs9R3eVjCaajZJG66Qa+NgUBQf7G10IAwvzJXZ9FIsQs17b
         5fNoVvCjKH+AE/7pKX282ui7MNcXuO6xlD8IRo1kzTf/+1M0DqbejiOGFc049hJc9Hrt
         q2pMYown+EZpAqqLWm47eyqK9XcrGisGQBkuk=
MIME-Version: 1.0
From: Jonathan Ellis <jbellis@gmail.com>
Date: Fri, 8 Jan 2010 13:47:33 -0600
Message-ID: <e06563881001081147u4259b189s1c0537bada90502f@mail.gmail.com>
Subject: release policy
To: cassandra-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

I think we have enough people using Cassandra in production now that
it would be useful to be explicit about the kinds of changes we will
make between major and minor releases.  Here is one possibility:

Minor releases (e.g. 0.4.0 -> 0.4.1): minor releases will contain bug
fixes only -- no new functionality, full disk and network-level
compatibility.  If bugs cannot be fixed without adding new
functionality or breaking compatibility, then it should probably not
be fixed in the stable branch unless it is very severe.  This is
similar to postgresql's minor release policy, and I really like it for
two reasons:
  (1) it makes a clear line of what people can expect in minor releases
  (2) making changes breaks stuff.  That's just how software is, so
the less we change in a stable branch the more likely it is that we
won't introduce regressions.  With our community's most enthusiastic
testers also the most interested in trunk rather than older releases,
it behooves us to be careful.

Major releases (e.g. 0.5 -> 0.6): the compatibility story is going to
be more nuanced:
  (1) sstable compatibility: may change.  If it does, we will notify
you in NEWS.txt and provide some method of upgrading without
dump-and-reload (and hopefully without downtime while a conversion
tool grinds away from old to new format, but I don't think we can
promise that with 100% certainty at this point).
  (2) commitlog compatibility: may change.  If it does, we will notify
you in NEWS.txt that you need to "nodeprobe flush" before upgrading,
as was the case for 0.4 -> 0.5.
  (3) network compatibility (from one cluster node to another): may
change.  If it does, we will notify you in NEWS.txt that you need to
upgrade the whole cluster at once, as was the case for 0.4 -> 0.5.
  (4) thrift api: We will make our best efforts to keep deprecated
methods will be available for one major release before being removed.
(e.g., get_key_range is deprecated in 0.5; it will be removed in the
next).  I do not anticipate having to make the kind of changes we made
from 0.3 to 0.4 (where we redid basically all the thrift structures,
and there was really no sane way to provide backwards compatibility),
but if we do we will notify you in NEWS.txt.
  (5) StorageProxy "fat client" api: This is still considered "mostly
an internal api," to be used if you are brave and need the extra
performance badly enough. :)  We probably won't render it
unrecognizably different since it's a fairly one-to-one mapping to the
thrift api, which has the above compatibility policy, but no promises.

Thoughts?  (Separate threads to follow re "the next major release
after 0.5 specifically," and "1.0.")

-Jonathan