add versioning notes to features in the manual
authorEvan Martin <martine@danga.com>
Sun, 17 Feb 2013 19:22:37 +0000 (11:22 -0800)
committerEvan Martin <martine@danga.com>
Sun, 17 Feb 2013 19:22:37 +0000 (11:22 -0800)
This helps guide which ninja version to depend on.

RELEASING
doc/manual.asciidoc

index 3f83c7b..0593e6d 100644 (file)
--- a/RELEASING
+++ b/RELEASING
@@ -3,7 +3,8 @@ Notes to myself on all the steps to make for a Ninja release.
 1. git checkout release; git merge master
 2. fix version number in source (it will likely conflict in the above)
 3. fix version in doc/manual.asciidoc
-4. rebuild manual, put in place on website
-5. commit, tag, push
-6. construct release notes from prior notes
+4. grep doc/manual.asciidoc for XXX, fix version references
+5. rebuild manual, put in place on website
+6. commit, tag, push
+7. construct release notes from prior notes
    credits: git shortlog -s --no-merges REV..
index 647f4d2..5a66904 100644 (file)
@@ -422,9 +422,7 @@ before building the targets requested by the user.
 Pools
 ~~~~~
 
-*Note: pools were added as an experiment and may be removed in a future
-version of Ninja.  Are they useful for you?  Let us know on the mailing
-list.*
+_Available since Ninja 1.1._
 
 Pools allow you to allocate one or more rules or edges a finite number
 of concurrent jobs which is more tightly restricted than the default
@@ -556,6 +554,8 @@ If you provide a variable named `builddir` in the outermost scope,
 Version compatibility
 ~~~~~~~~~~~~~~~~~~~~~
 
+_Available since Ninja 1.XXX._
+
 Ninja version labels follow the standard major.minor.patch format,
 where the major version is increased on backwards-incompatible
 syntax/behavioral changes and the minor version is increased on new