Chip,
On Mon, Jul 1, 2013 at 4: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) > Do we produce packages before feature freeze? Provided that we don't produce packages until the freeze, my thinking is that we would identify the version number at the time the release branch gets cut. I think it is an extremely low (near nothing) probability that we would elect to take on a backwards compatibility breaking patch after freeze. > 2) DB version string, especially for testing upgrades > I think we should be considering a different versioning scheme for database schemas that better accounts for the concurrent nature of development. By way of example, Flyway [1] has such an approach which helps sequencing database changes made concurrently in different branches. In the release documentation, we would simply capture the associated schema version number (e.g. 4.2.0 uses schema version 342312). > > 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. > I completely agree that we would have to accept such a change carefully as a community, and seek to minimize the occurrence. My thinking is that we recognize that we likely won't know going into a release cycle that we have such a change (or set of changes) coming. My thought is that the messaging for such a change would be significant, and that it would be nice to remove the additional complexity of explaining, "You knew this release as 4.x, but now we are calling it 5.0.0". > > -chip > [1]: http://flywaydb.org/
