svn commit: r1680440 - /accumulo/site/trunk/content/release_notes/1.7.0.mdtext

[el...@apache.org]

Author: elserj
Date: Wed May 20 02:11:47 2015
New Revision: 1680440

URL: http://svn.apache.org/r1680440
Log:
ACCUMULO-3737 Restore deleted additions from ctubbsii reformatting

Modified:
    accumulo/site/trunk/content/release_notes/1.7.0.mdtext

Modified: accumulo/site/trunk/content/release_notes/1.7.0.mdtext
URL: http://svn.apache.org/viewvc/accumulo/site/trunk/content/release_notes/1.7.0.mdtext?rev=1680440&r1=1680439&r2=1680440&view=diff
==============================================================================
--- accumulo/site/trunk/content/release_notes/1.7.0.mdtext (original)
+++ accumulo/site/trunk/content/release_notes/1.7.0.mdtext Wed May 20 02:11:47 2015
@@ -23,11 +23,11 @@ issues were resolved in this version. Ap
 one-third were improvements.
 
 In the context of Accumulo's [Semantic Versioning][semver] [guidelines][api],
-this is a "minor version". This means that new APIs have been created, but no
-deprecated APIs have been removed. Code written against 1.6.x should work
-against 1.7.0 (though it may require re-compilation). As always, the Accumulo
-developers take API compatibility very seriously and have invested much time
-to ensure that we meet the promises set forth to our users.
+this is a "minor version". This means that new APIs have been created, some
+deprecations may have been added, but no deprecated APIs have been removed.
+Code written against 1.6.x should work against 1.7.0, likely binary-compatible
+but definitely source-compatible. As always, the Accumulo developers take API compatibility
+very seriously and have invested much time to ensure that we meet the promises set forth to our users.
 
 # Major Changes #
 
@@ -187,7 +187,7 @@ remove the limitation when sufficient se
 
 When ingesting data into Accumulo, the majority of time is spent in the
 write-ahead log. As such, this is a common place that optimizations are added.
-One optimization is the notion of "group-commit". When multiple clients are
+One optimization is known as "group-commit". When multiple clients are
 writing data to the same Accumulo tablet, it is not efficient for each of them
 to synchronize the WAL, flush their updates to disk for durability, and then
 release the lock. The idea of group-commit is that multiple writers can queue
@@ -205,7 +205,7 @@ encouraged sub-par performance with few
 queued before a group-commit is performed in such a way that is agnostic of
 the number of writers. This new configuration property is much easier to
 reason about than the previous (now deprecated) `tserver.mutation.queue.max`.
-Users who have altered `tserver.mutation.queue.max` in the past are encouraged
+Users who have set `tserver.mutation.queue.max` in the past are encouraged
 to start using the new `tserver.total.mutation.queue.max` property.
 
 # Other improvements #