svn commit: r1644824 - in /phoenix/site: publish/upgrading.html source/src/site/markdown/upgrading.md

[ja...@apache.org]

Author: jamestaylor
Date: Fri Dec 12 04:09:55 2014
New Revision: 1644824

URL: http://svn.apache.org/r1644824
Log:
Fix typo

Modified:
    phoenix/site/publish/upgrading.html
    phoenix/site/source/src/site/markdown/upgrading.md

Modified: phoenix/site/publish/upgrading.html
URL: http://svn.apache.org/viewvc/phoenix/site/publish/upgrading.html?rev=1644824&r1=1644823&r2=1644824&view=diff
==============================================================================
--- phoenix/site/publish/upgrading.html (original)
+++ phoenix/site/publish/upgrading.html Fri Dec 12 04:09:55 2014
@@ -130,7 +130,7 @@
  <h1>Upgrading Phoenix</h1>
 </div> 
 <p>Phoenix uses a three number versioning schema of the form &lt;major version&gt;.&lt;minor version&gt;.&lt;patch version&gt;. For example, 4.2.1 has a major version of 4, a minor version of 2, and a patch version of 1.</p> 
-<p>When upgrading to a new minor release (i.e. the major version is the same, but the minor version has changed), sometimes modifications to the system tables are necessary to either fix a bug or provide a new feature. This upgrade will occur automatically the first time a newly upgraded client connects to the newly upgraded server. It is expected that the server-side jar is upgraded first across your entire cluster, before any clients are upgraded. An older client will work with a newer server jar when the minor version is different, but not visa versa. In other words, clients do not need to be upgraded in lock step with the server. However, as of 4.2 and below, it is expected that all clients are upgraded at the same time (i.e. a mix of clients with different versions will not necessarily change). This may be improved in the future to allow a mix of old and new client versions (<a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-1483">PHOENIX-1483</a>)</p> 
+<p>When upgrading to a new minor release (i.e. the major version is the same, but the minor version has changed), sometimes modifications to the system tables are necessary to either fix a bug or provide a new feature. This upgrade will occur automatically the first time a newly upgraded client connects to the newly upgraded server. It is expected that the server-side jar is upgraded first across your entire cluster, before any clients are upgraded. An older client will work with a newer server jar when the minor version is different, but not visa versa. In other words, clients do not need to be upgraded in lock step with the server. However, as of 4.2 and below, it is expected that all clients are upgraded at the same time (i.e. a mix of clients with different versions will not necessarily change). This may be improved in the future to allow a mix of old and new client versions (<a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-1483">PHOENIX-1483</a>).</p>
  
 <p>Upgrading to a new patch release may occur in any order: client first or server first, and a mix of clients with different patch release versions is fine.</p> 
 <p>Upgrading to a new major release may require downtime as well as potentially the running of a migration script. This will be determined on a release by release basis.</p> 
 <div class="section"> 

Modified: phoenix/site/source/src/site/markdown/upgrading.md
URL: http://svn.apache.org/viewvc/phoenix/site/source/src/site/markdown/upgrading.md?rev=1644824&r1=1644823&r2=1644824&view=diff
==============================================================================
--- phoenix/site/source/src/site/markdown/upgrading.md (original)
+++ phoenix/site/source/src/site/markdown/upgrading.md Fri Dec 12 04:09:55 2014
@@ -2,7 +2,7 @@
 
 Phoenix uses a three number versioning schema of the form &lt;major version&gt;.&lt;minor version&gt;.&lt;patch version&gt;. For example, 4.2.1 has a major version of 4, a minor version of 2, and a patch version of 1.
 
-When upgrading to a new minor release (i.e. the major version is the same, but the minor version has changed), sometimes modifications to the system tables are necessary to either fix a bug or provide a new feature. This upgrade will occur automatically the first time a newly upgraded client connects to the newly upgraded server. It is expected that the server-side jar is upgraded first across your entire cluster, before any clients are upgraded. An older client will work with a newer server jar when the minor version is different, but not visa versa. In other words, clients do not need to be upgraded in lock step with the server. However, as of 4.2 and below, it is expected that all clients are upgraded at the same time (i.e. a mix of clients with different versions will not necessarily change). This may be improved in the future to allow a mix of old and new client versions ([PHOENIX-1483](https://issues.apache.org/jira/browse/PHOENIX-1483))
+When upgrading to a new minor release (i.e. the major version is the same, but the minor version has changed), sometimes modifications to the system tables are necessary to either fix a bug or provide a new feature. This upgrade will occur automatically the first time a newly upgraded client connects to the newly upgraded server. It is expected that the server-side jar is upgraded first across your entire cluster, before any clients are upgraded. An older client will work with a newer server jar when the minor version is different, but not visa versa. In other words, clients do not need to be upgraded in lock step with the server. However, as of 4.2 and below, it is expected that all clients are upgraded at the same time (i.e. a mix of clients with different versions will not necessarily change). This may be improved in the future to allow a mix of old and new client versions ([PHOENIX-1483](https://issues.apache.org/jira/browse/PHOENIX-1483)).
 
 Upgrading to a new patch release may occur in any order: client first or server first, and a mix of clients with different patch release versions is fine.