Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of jburwell@basho.com designates
 209.85.216.54 as permitted sender)
From: John Burwell <jburwell@basho.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: In-Development Release Naming
Message-Id: <2F5E56AA-A9C9-4576-9410-0B305E9FA312@basho.com>
Date: Mon, 1 Jul 2013 14:28:37 -0400
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))

All,

Since we have adopted Semantic Versioning [1], it seems odd that we =
designate a release version before the final set of enhancements/fixes =
has been identified.  For example, the release proceeding 4.2 may =
contain no backwards compatible API changes to be 4.3.  Conversely, we =
may decide during the development cycle, as a community, to accept a =
non-backwards compatible change which would bump the version to 5.0.0.  =
As such, it is difficult to know in advance what the proper semantic =
version number will be at when the work is released.  We run the risk of =
confusing our users if we start calling a pending release say 4.3.0, and =
accept a change mid-cycle that will bump it to 5.0.0.  To address this =
potential issue, I proposed that we refer to releases by a codename =
until feature freeze when we understand the complete scope of change and =
can apply the correct semantic version number.  I further propose we =
codename the release directly proceeding 4.2 "Gamma Rays" or "Gamma Rays =
Gonna Get Ya". =20

Thoughts?
-John

[1]: http://semver.org=