Add consistent versionadded/deprecated tags.

rst/bestpractices.rst

@@ -82,8 +82,12 @@ You may wish to construct simple shell scripts to wrap calls to ansible-playbook
 Bundling Ansible Modules With Playbooks
 +++++++++++++++++++++++++++++++++++++++
 
-In version 0.5 and later, if a playbook has a "./library" directory relative to it's YAML file, this directory can be used to add ansible modules that will automatically be in the ansible module path.  This is a great way to keep modules that
-go with a playbook together.
+.. versionadded:: 0.5
+
+If a playbook has a "./library" directory relative to it's YAML file,
+this directory can be used to add ansible modules that will
+automatically be in the ansible module path.  This is a great way to
+keep modules that go with a playbook together.
 
 Miscellaneous Tips
 ++++++++++++++++++

rst/gettingstarted.rst

@@ -132,10 +132,12 @@ By default, ansible uses paramiko to talk to managed nodes over SSH.  Paramiko i
 very transparently, requires no configuration, and is a good choice for most users.
 However, it does not support some advanced SSH features that folks will want to use.
 
-Starting in version 0.5, if you want to leverage more advanced SSH features (such as Kerberized SSH or jump hosts), 
-pass the flag "--connection=ssh" to any ansible command, or set the
-ANSIBLE_TRANSPORT environment variable to 'ssh'. This will cause Ansible to use openssh
-tools instead.  
+.. versionadded:: 0.5
+
+If you want to leverage more advanced SSH features (such as Kerberized
+SSH or jump hosts), pass the flag "--connection=ssh" to any ansible
+command, or set the ANSIBLE_TRANSPORT environment variable to
+'ssh'. This will cause Ansible to use openssh tools instead.
 
 If ANSIBLE_SSH_ARGS are not set, ansible will try to use some sensible ControlMaster options
 by default.  You are free to override this environment variable, but should still pass ControlMaster

rst/modules.rst

@@ -96,11 +96,15 @@ Example action from Ansible :doc:`playbooks`::
 assemble
 ````````
 
-(new in 0.5) Assembles a configuration file from fragments.   Often a particular program will take a single configuration file
-and does not support a conf.d style structure where it is easy to build up the configuration from multiple sources.
-Assmeble will take a directory of files that have already been transferred to the system, and concatenate them
-together to produce a destination file.  Files are assembled in string sorting order.   Puppet calls this idea
-"fragments".
+.. versionadded:: 0.5
+
+Assembles a configuration file from fragments.  Often a particular
+program will take a single configuration file and does not support a
+conf.d style structure where it is easy to build up the configuration
+from multiple sources.  Assmeble will take a directory of files that
+have already been transferred to the system, and concatenate them
+together to produce a destination file.  Files are assembled in string
+sorting order.  Puppet calls this idea "fragments".
 
 +--------------------+----------+---------+----------------------------------------------------------------------------+
 | parameter          | required | default | comments                                                                   |
@@ -122,7 +126,9 @@ Example action from Ansible :doc:`playbooks`::
 authorized_key
 ``````````````
 
-(new in 0.5).  Adds or removes an authorized key for a user from a remote host.
+.. versionadded:: 0.5
+
+Adds or removes an authorized key for a user from a remote host.
 
 +--------------------+----------+---------+----------------------------------------------------------------------------+
 | parameter          | required | default | comments                                                                   |

rst/patterns.rst

@@ -144,9 +144,11 @@ seperate from the inventory file, see the next section.
 Splitting Out Host and Group Specific Data
 ++++++++++++++++++++++++++++++++++++++++++
 
-In Ansible 0.6 and later, in addition to the storing variables directly in the INI file, host and
-group variables can be stored in individual files relative to the inventory file.  These
-variable files are in YAML format.
+.. versionadded:: 0.6
+
+In addition to the storing variables directly in the INI file, host
+and group variables can be stored in individual files relative to the
+inventory file.  These variable files are in YAML format.
 
 Assuming the inventory file path is::
 
@@ -172,14 +174,19 @@ It is ok if these files do not exist, this is an optional feature.
 Tip: Keeping your inventory file and variables in a git repo (or other version control) 
 is an excellent way to track changes to your inventory and host variables.
 
-Tip: If you ever have two python interpreters on a system, set a variable called 'ansible_python_interpreter' to
-the Python interpreter path you would like to use.
+.. versionadded:: 0.5
+   If you ever have two python interpreters on a system, set a
+   variable called 'ansible_python_interpreter' to the Python
+   interpreter path you would like to use.
 
 YAML Inventory
 ++++++++++++++
 
-Ansible's YAML inventory format is deprecated and will be removed in Ansible 0.7.  Ansible 0.6 includes
-a `conversion script <https://github.com/ansible/ansible/blob/devel/examples/scripts/yaml_to_ini.py>`_.
+.. deprecated:: 0.7
+
+Ansible's YAML inventory format is deprecated and will be removed in
+Ansible 0.7.  Ansible 0.6 includes a `conversion script
+<https://github.com/ansible/ansible/blob/devel/examples/scripts/yaml_to_ini.py>`_.
 
 Usage::
 

rst/playbooks2.rst

@@ -9,8 +9,11 @@ be 90% or more of what they use in Ansible.
 Tags
 ````
 
-(New in 0.6) If you have a large playbook it may become useful to be able to run a specific
-part of the configuration.  Both plays and tasks support a "tags:" attribute for this reason.
+.. versionadded:: 0.6
+
+If you have a large playbook it may become useful to be able to run a
+specific part of the configuration.  Both plays and tasks support a
+"tags:" attribute for this reason.
 
 Example::
 
@@ -34,10 +37,13 @@ If you wanted to just run the "configuration" and "packages" part of a very long
 Playbooks Including Playbooks
 `````````````````````````````
 
-(New in 0.6) To further advance the concept of include files, playbook files can include other playbook
-files.  Suppose you define the behavior of all your webservers in "webservers.yml" and
-all your database servers in "dbservers.yml".  You can create a "site.yml" that would
-reconfigure all of your systems like this::
+.. versionadded:: 0.6
+
+To further advance the concept of include files, playbook files can
+include other playbook files.  Suppose you define the behavior of all
+your webservers in "webservers.yml" and all your database servers in
+"dbservers.yml".  You can create a "site.yml" that would reconfigure
+all of your systems like this::
 
     ----
     - include: playbooks/webservers.yml
@@ -49,8 +55,11 @@ what parts of those plays.
 Ignoring Failed Commands
 ````````````````````````
 
-(New in 0.6) Generally playbooks will stop executing any more steps on a host that has a failure.
-Sometimes, though, you want to continue on.  To do so, write a task that looks like this::
+.. deprecated:: 0.6
+
+Generally playbooks will stop executing any more steps on a host that
+has a failure.  Sometimes, though, you want to continue on.  To do so,
+write a task that looks like this::
 
     - name: this will not be counted as a failure
       action: command /bin/false