You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Sean Busbey <bu...@cloudera.com> on 2013/10/25 21:43:56 UTC
Accumulo Versions (was Accumulo feature freeze in 1 week)
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
Re: Accumulo Versions (was Accumulo feature freeze in 1 week)
Posted by Eric Newton <er...@gmail.com>.
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 <bu...@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 <jo...@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
>> >
>>
Re: Accumulo Versions (was Accumulo feature freeze in 1 week)
Posted by Keith Turner <ke...@deenlo.com>.
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 <bu...@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 <jo...@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
> >
>
Re: Accumulo Versions (was Accumulo feature freeze in 1 week)
Posted by John Vines <vi...@apache.org>.
+1 marketing.major.minor
On Fri, Oct 25, 2013 at 3:58 PM, Sean Busbey <bu...@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 <jo...@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
>
Re: Accumulo Versions (was Accumulo feature freeze in 1 week)
Posted by Sean Busbey <bu...@cloudera.com>.
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 <jo...@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
Re: Accumulo Versions (was Accumulo feature freeze in 1 week)
Posted by Josh Elser <jo...@gmail.com>.
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
>
Re: Accumulo Versions (was Accumulo feature freeze in 1 week)
Posted by Bill Havanki <bh...@cloudera.com>.
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 <mb...@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 <ct...@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 <bu...@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
// - - -
Re: Accumulo Versions (was Accumulo feature freeze in 1 week)
Posted by Corey Nolet <cj...@gmail.com>.
Adding to above- I've been seeing the minor as the bugfix and the major as
the "new feature and possible API changes" version. I'm all for following
Maven's lead but what would that transition look like? Does that mean there
would be a 2.0 coming out soon?
On Fri, Oct 25, 2013 at 10:44 PM, Corey Nolet <cj...@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 <mb...@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 <ct...@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 <bu...@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
>> >
>>
>
>
Re: Accumulo Versions (was Accumulo feature freeze in 1 week)
Posted by Christopher <ct...@apache.org>.
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 <cj...@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 <mb...@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 <ct...@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 <bu...@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
>> >
>>
Re: Accumulo Versions (was Accumulo feature freeze in 1 week)
Posted by Corey Nolet <cj...@gmail.com>.
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 <mb...@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 <ct...@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 <bu...@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
> >
>
Re: Accumulo Versions (was Accumulo feature freeze in 1 week)
Posted by Michael Berman <mb...@sqrrl.com>.
>
> 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 <ct...@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 <bu...@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
>
Re: Accumulo Versions (was Accumulo feature freeze in 1 week)
Posted by Christopher <ct...@apache.org>.
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 <bu...@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