DOCS-728 and DOCS-726 updates to release notes for 2.2.1

Author: Sam Kleinman

source/release-notes/2.2.txt

@@ -20,40 +20,33 @@ MongoDB 2.0 data files are compatible with 2.2-series binaries without any
 special migration process. However, always perform the upgrade process for replica
 sets and sharded clusters using the procedures that follow.
 
+Always upgrade to the latest point release in the 2.2 point
+release. Currently the latest release of MongoDB is |release|.
+
 Synopsis
 ~~~~~~~~
 
-- When upgrading a standalone :program:`mongod`, 2.2 is a drop-in
-  replacement.
-
-- For all deployments using authentication, you *must* upgrade the
-  drivers (i.e. client libraries), before upgrading the
-  :program:`mongod` instance or instances.
-
-.. To keep with what people are used to, we really should move the comma
-   outside the parens.
+- :program:`mongod`, 2.2 is a drop-in replacement for 2.0 and 1.8.
 
-- You can upgrade the members of a replica set one-by-one
-  [#secondaries-first]_ **except** when using authentication. In
-  deployments that use authentication (i.e. where the
-  :program:`mongod` runs with :option:`--keyFile <mongod --keyFile>`),
-  you must shut down the entire set and perform the upgrade at once.
+- Check your :doc:`driver </applications/drivers>` documentation for
+  information regarding required compatibility upgrades, and always
+  run the recent release of your driver.
 
-  The 2.2.1 release will remove this requirement. See
-  :issue:`SERVER-6897` for more information.
+  Typically, only users running with authentication, will need to
+  upgrade drivers before continuing with the upgrade to 2.2.
 
-- For all upgrades of sharded clusters, turn off the balancer during
-  the upgrade process. See the
-  :ref:`sharding-balancing-disable-temporally` section for more
-  information.
-
-- For sharded clusters running with authentication, you must:
+- For all deployments using authentication, upgrade the
+  drivers (i.e. client libraries), before upgrading the
+  :program:`mongod` instance or instances.
 
-  - First, disable the balancer and upgrade the client drivers.
+- For all upgrades of sharded clusters:
 
-  - Second, upgrade all :program:`mongos` instances.
+  - turn off the balancer during the upgrade process. See the
+    :ref:`sharding-balancing-disable-temporally` section for more
+    information.
 
-  - Last, upgrade all :program:`mongod` instances.
+  - upgrade all :program:`mongos` instances before upgrading any
+    :program:`mongod` instances.
 
 Other than the above restrictions, 2.2 processes can interoperate with
 2.0 and 1.8 tools and processes. You can safely upgrade the
@@ -72,7 +65,8 @@ systems.
 Upgrading a Standalone ``mongod``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-#. Download the v2.2 binaries from the `MongoDB Download Page`_.
+#. Download binaries of the latest release in the 2.2 series from the
+   `MongoDB Download Page`_.
 
 #. Shutdown your :program:`mongod` instance. Replace the existing
    binary with the 2.2 :program:`mongod` binary and restart MongoDB.
@@ -84,15 +78,7 @@ Upgrading a Standalone ``mongod``
 Upgrading a Replica Set
 ~~~~~~~~~~~~~~~~~~~~~~~
 
-For replica sets running with authentication, (i.e. :option:`--keyFile
-<mongod --keyFile>`), upgrade the entire set to
-2.2 at once. Shut down all :program:`mongod` instances in the set
-cleanly, upgrade the binaries, and then restart all instances.
-
-The 2.2.1 release, will remove this "hard" upgrade requirement, see
-:issue:`SERVER-6897`.
-
-If your set does not run with authentication, you perform a "rolling"
+You can upgrade to 2.2 by performing a "rolling"
 upgrade of the set by upgrading the members individually while the
 other members are available to minimize downtime. Use the following
 procedure: