X-Git-Url: https://git.gag.com/?a=blobdiff_plain;f=doc%2Fmanual%2Frelease.txt;h=44de4464f5c059e368da283b9ab3dfa1c5d24582;hb=8abe91cff960709ffd3ebbb9eb1dcf710dd83c1f;hp=d1447569204b217380f6432fb79c7e14845500da;hpb=90142e3edb55f03134b4ff2a96fb2dd041dbdf17;p=fw%2Fopenocd
diff --git a/doc/manual/release.txt b/doc/manual/release.txt
index d14475692..44de4464f 100644
--- a/doc/manual/release.txt
+++ b/doc/manual/release.txt
@@ -36,7 +36,7 @@ several important advantages compared to using the source repository
were produced as part of creating the archive.
-# Because they have been formally released by the project, users
don't need to try a random work-in-process revision. Releasing
- involves spending some time specifically on quality improvments,
+ involves spending some time specifically on quality improvements,
including bugfixing source code and documentation.
-# They provide developers with the flexibility needed to address
larger issues, which sometimes involves temporary breakage.
@@ -149,7 +149,7 @@ specific git revisions:
0.3.0-rc1-dev-00015-gf37c9b8-dirty
-indicates a development tree based on git revison f37c9b8
+indicates a development tree based on git revision f37c9b8
(a truncated version of a SHA1 hash) with some non-git
patches applied (the dirty tag). This information
can be useful when tracking down bugs.
@@ -334,7 +334,7 @@ git tag -m "The openocd-${PACKAGE_VERSION} release." "${PACKAGE_TAG}"
configuring its contents, using them to build a copy of OpenOCD,
and verifying that the result prints the correct release version
in its startup banner. (For example,
- "configure --enable-ft2232_libftdi --enable-parport"
+ "configure --enable-parport"
then "make" and run "src/openocd -v" as a sanity check.)
-# Run make docs
to create the
documentation which will be published.
@@ -385,7 +385,7 @@ git tag -m "The openocd-${PACKAGE_VERSION} release." "${PACKAGE_TAG}"
- Last updates for the release, including the release tag (you
will need to "git push --tags").
- Updates opening the merge window
- - At this point, it's OK for commiters to start pushing changes
+ - At this point, it's OK for committers to start pushing changes
which have been held off until the next release. (Any bugfixes to
this release will be against a bug-fix release branch starting from
the commit you tagged as this release, not mainline.)
@@ -423,7 +423,7 @@ tools/release.sh --type=micro branch
Both of these variations make automatic commits and tags in your
repository, so you should be sure to run it on a cloned copy before
-proceding with a live release.
+proceeding with a live release.
@subsection releasescriptopts Release Script Options