When explaining X.major.minor versioning to people, I generally refer to X as the "marketing" version. It gets incremented when the project wants to push for a separation in the minds of users.
On Fri, Oct 25, 2013 at 2:50 PM, Josh Elser <josh.el...@gmail.com> wrote: > That is a good point. > > We typically have referred to 1.x releases as "major". I will say that > when I wrote up the Git document, I wrote it based on how we refer to our > versions, not necessarily using correct semantic versioning verbage. > > Is the "1" or "1.6.0" the "super-major" version? :P > > > On 10/25/13 12:43 PM, Sean Busbey wrote: > >> On the feature freeze reminder thread, Chris said: >> >> I don't mind putting things off to 1.7 (if necessary). But... if 1.6.0 >>> isn't sufficiently feature rich, there's not really a reason to >>> release it just yet... until those features are ready. That said, I do >>> think there'll be enough features in 1.6.0 to release it as a minor >>> release, if we're interpreting the version as the standard >>> <major>.<minor>.<bugfix> scheme, even if we end up pushing some stuff >>> off to 1.7. >>> >> >> I didn't want to derail that thread, but this does not line up with what >> I've seen in Accumulo. (Though I agree that it is a common numbering >> scheme[1]) >> >> The Accumulo release guide[2] doesn't specify how "minor" and "major" turn >> into positions in the version number. However, the git workflow guide[3] >> does, and basically says that Accumulo uses >> >> x.y.z >> >> y = major >> z = minor >> >> This also lines up with my understanding of previous Accumulo releases and >> cross-compatibility amongst them. >> >> >> [1]: http://semver.org/spec/v2.0.0.**html<http://semver.org/spec/v2.0.0.html> >> [2]: >> http://accumulo.apache.org/**governance/releasing.html<http://accumulo.apache.org/governance/releasing.html> >> [3]: >> http://accumulo.apache.org/**git.html#release-management<http://accumulo.apache.org/git.html#release-management> >> >> -- Sean
