Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo >> mail # dev >> Accumulo Versions (was Accumulo feature freeze in 1 week)


+
Sean Busbey 2013-10-25, 19:43
+
Josh Elser 2013-10-25, 19:50
+
Sean Busbey 2013-10-25, 19:58
+
John Vines 2013-10-25, 20:22
+
Keith Turner 2013-10-25, 22:29
+
Eric Newton 2013-10-26, 01:01
+
Christopher 2013-10-26, 01:07
+
Michael Berman 2013-10-26, 02:31
+
Bill Havanki 2013-10-28, 13:15
+
Corey Nolet 2013-10-26, 02:44
Copy link to this message
-
Re: Accumulo Versions (was Accumulo feature freeze in 1 week)
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> 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
+
Corey Nolet 2013-10-26, 02:47