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
