I'll add my +1 to Christopher's suggestions. Sticking with the
major/minor/bugfix standard will make it easier for other projects and our
users to interpret our version numbers. They really are just a message to
everyone summarizing the nature of what changed. I don't worry about
incrementing numbers "too fast", it's not like we'll run out. :)
I've always treated them as Michael does: a bugfix release is safe as a
drop-in replacement; a minor release may require a recompile and adds some
new functionality; a major release is a large change (overhaul, in Eric's
words) that will certainly break your stuff.
Bill
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
> >
>
--
// - - -
// Bill Havanki
// Solutions Architect, Cloudera
// - - -
