I think it's more like: overhaul.major.minor
Minor: bug fixes Major: small, gradual API changes Overhaul: for the love of all that is holy... what have you done?!? For example... changing the API of Iterators, switching away from thrift or zookeeper, or losing the backwards compatibility of RFiles, re-write everything in a different language and other project-killing ideas. Arguably the name changes that occurred with the transition to Apache was a (necessary) overhaul. If that was marketing, I think we were doing it wrong. -Eric On Fri, Oct 25, 2013 at 6:29 PM, Keith Turner <ke...@deenlo.com> wrote: > On Fri, Oct 25, 2013 at 4:22 PM, John Vines <vi...@apache.org> wrote: > >> +1 marketing.major.minor >> > > For x.y.z, Christopher and I have discussed only incrementing x when > deprecated methods are dropped. > > > >> >> >> On Fri, Oct 25, 2013 at 3:58 PM, Sean Busbey <bus...@cloudera.com> wrote: >> >> > 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 >> > >>
