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
[2]: http://accumulo.apache.org/governance/releasing.html
[3]: http://accumulo.apache.org/git.html#release-management
