Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

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


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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB