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 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
Copy link to this message
-
Re: Accumulo Versions (was Accumulo feature freeze in 1 week)
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
>> 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
+
Michael Berman 2013-10-26, 02:31
+
Bill Havanki 2013-10-28, 13:15
+
Corey Nolet 2013-10-26, 02:44
+
Christopher 2013-10-26, 03:20
+
Corey Nolet 2013-10-26, 02:47
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