Definitely not formalized, but would be nice to do so. Regarding your other reply, regarding a possible 2.0, we could establish these in by-laws, and begin these practices more strictly with a 2.0 (maybe instead of a 1.7).
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, Oct 25, 2013 at 10:44 PM, Corey Nolet <cjno...@gmail.com> wrote: > bq. For instance, we could establish rules like... > > I thought these were already excepted practices. Have they not been > formalized? Other than the backporting, haven't we been following all of > those rules already? > > > On Fri, Oct 25, 2013 at 10:31 PM, Michael Berman <mber...@sqrrl.com> wrote: > >> > >> > No public API changes between minor and bugfix releases (API semantic >> > changes are okay, if they fix a bug). >> > Major features are incorporated into major releases. >> > API compatibility is not guaranteed between major releases (deprecated >> > methods can be dropped). >> > Deprecated API must persist as deprecated through at least one major >> > release before removing. >> > Minor releases include changes and improvements to existing features, >> > but not major new features or drastic changes. >> >> >> +1 to all of that! It's really nice to know that I always want the latest >> available o.o.X and that it's always totally safe to update to, and that >> while things may have changed in the next o.X.o, at least I won't have to >> make any major changes to my client code. Of course this implies that the >> MSV should increment faster than if often does in these kinds of projects, >> but I think that's ok. The longer you go without ever bumping the first >> digit, the bigger the change seems like it needs to be to justify finally >> doing so. >> >> >> On Fri, Oct 25, 2013 at 9:07 PM, Christopher <ctubb...@apache.org> wrote: >> >> > You're right, historically, Accumulo has considered y = major, and z = >> > minor/bugfix, by convention. This is because our iterative development >> > process hasn't really lent itself to feature planning for releases. >> > However, in the quoted thread, I was simply providing a definition of >> > a term ("minor") when I used it, so that I could not possibly be >> > misunderstood. >> > >> > However, since we're on the subject. we need to do better than our >> > previous conventions for versioning... because we need to establish a >> > better stability in our API contracts. Since not long after we >> > switched to using Maven, in the early days of the code, we've at least >> > tried to follow maven conventions, and the semantics of versioning is >> > one of them. Following it (major.minor.bugfix) more strictly can help >> > us make API compatibility guarantees that we can actually enforce, and >> > can help with long-term support. >> > >> > For instance, we could establish rules like: >> > >> > No public API changes between minor and bugfix releases (API semantic >> > changes are okay, if they fix a bug). >> > Major features are incorporated into major releases. >> > API compatibility is not guaranteed between major releases (deprecated >> > methods can be dropped). >> > Deprecated API must persist as deprecated through at least one major >> > release before removing. >> > Minor releases include changes and improvements to existing features, >> > but not major new features or drastic changes. >> > >> > I can't say which specific rules we'd want to establish, but having >> > some in place could definitely ease the conflicts between development >> > of new features and support for old ones. >> > >> > -- >> > Christopher L Tubbs II >> > http://gravatar.com/ctubbsii >> > >> > >> > On Fri, Oct 25, 2013 at 3:43 PM, Sean Busbey <bus...@cloudera.com> >> 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 >> > > >> > > -- >> > > Sean >> > >>
