That doesn't invalidate John's point about the message to the users. We can publish it by a code name and still code it with numbers according to our expectations of the level of bump it will take.
On Mon, Jul 1, 2013 at 10:15 PM, Chip Childers <chipchild...@apache.org>wrote: > On Mon, Jul 01, 2013 at 02:28:37PM -0400, John Burwell wrote: > > 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". > > > > Thoughts? > > -John > > > > [1]: http://semver.org > > Some technical issues to address WRT versions prior to a number being > assigned: > > 1) package version strings (DEB and RPM) > 2) DB version string, especially for testing upgrades > > Thoughts on how to avoid issues here? > > To me, it seems like we should make an upgrade to 5.x a *major discussion*, > and instead *assume* that we will retain backward compatibility and not > bump > the major number. I'd rather limit the number of times that we > actually jump major versions and take the hit on the version numbering > changes when those times to occur. Just my 2 cents though. > > -chip >
