On Jul 2, 2013, at 1:31 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:
> John, > > If I understand you, we will call master x.(y+1) with x.y being the latest > unpatched release unless we decide that it is not going to be x-compatible > anymore. We will publish x.(y+1) as some symbolic name, possibly reflecting > a running gag from the latest collab, until it is decided whether it will > be x.(y+1) or (x+1).0. > > I think it will have to have a semantic number on master or patch branches, > for people to be able to cook their own packages. > > As for your schema versions, is the scheme you are proposing not just > adding administration. Flyway seems like a good tool but does it solve > concurrent upgrades i.e. 4.1.3 has an upgrade to 4.1.2 and 4.2.0 has a > similar but not equal upgrade. Will we have the obvious manual work on > 4.1.3 -> 4.2.0 or will flyway help us smoothen this path. > > regards, > I read the thread but I am missing the point of having codenames. We have JIRA to track features and tag them properly, we have feature branches to develop them. Before cutting branches an RM should know what's in there -as well as most of us- and if major changes are being merged, a discussion should be triggered on the list to see if this warrants a major version number bump. So imho, when the branch is cut we know what's in it and we agree to the version number. To me, codenames are confusing . I'd rather see a clear message like "we are bumping the release number to version x.y because of this major feature…." than start talking about a " "gammaray" pre-RC dev release that will later maybe become x.y but we are not sure." -Sebastien > > > On Mon, Jul 1, 2013 at 10:45 PM, John Burwell <jburw...@basho.com> wrote: > >> 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/ >>
