On Mon, Jul 01, 2013 at 10:40:38PM +0200, Daan Hoogland wrote: > 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.
Ah... I guess I was thinking that this was an all-inclusive proposal. Sounds fine to me. I'd suggest that 4.2 is out of the bag now, but how about for our next feature release? > > > 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 > >
