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.221 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=EK3o1oKxxMkljcoFgtQkWfVeMp+rheG09bQ/P/PilTrL1Laq0kOww2JX/7YnoKr5FM
         65fhcmtT9F9ceh825qe1CzzaYVDTUtrKPlPN87SWCe2GfJfEZqI1OL/voBRPIBScXuoH
         WPBNEjH/tcah1/IdjWOfI23eBcIhfEx+qcI+c=
MIME-Version: 1.0
Date: Mon, 29 Jun 2009 23:04:46 -0500
Message-ID: <e06563880906292104h103aaefdh2c07529b761df9ab@mail.gmail.com>
Subject: The future of 0.3
From: Jonathan Ellis <jbellis@gmail.com>
To: cassandra-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

With 0.3.0 voted in (the mentors technically have the last word, but
let's assume it does get approved :), we should think about the future
of the 0.3 branch.

Fundamentally 0.3 has issues (see BUGS.txt) and fixing those issues
would turn it into 0.4, so I see the 0.3 maintenance mission as very
limited in scope.  It's there to show we CAN release and to give
non-developers a stable branch to use until we're done breaking
things. :)

I'm a huge fan of the postgresql model for database release
management.  New features go into major versions (8.3, 8.4, etc.) and
maintenance releases (8.4.1, 8.4.2, etc.) are only for bug and
security fixes.  That's the only way to stay sane IMO; once you start
trying to do things like backport new shiny features you WILL have
regressions.  And stable branches are all about NOT having those. :)

So I propose fixing bugs but otherwise doing the minimum possible to
disturb things in 0.3 until 0.4.0 is out, and encouraging people to
migrate to that quickly when it is.

-Jonathan