accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: Accumulo Versions (was Accumulo feature freeze in 1 week)
Date Sat, 26 Oct 2013 03:20:31 GMT
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 <cjnolet@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 <mberman@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 <ctubbsii@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 <busbey@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
>> >
>>

Mime
View raw message