From 9da9e247ed2a24510b84fc541b21d72fa1912cdc Mon Sep 17 00:00:00 2001 From: Roger Luethi Date: Wed, 21 May 2014 19:07:39 +0200 Subject: [PATCH] Fix typos in docs Change-Id: I547e99c24707895c1e3614821c5cb8da354b294a --- doc/source/index.rst | 8 ++++---- doc/source/semver.rst | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/source/index.rst b/doc/source/index.rst index 590bb94b..f4d604ec 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -65,10 +65,10 @@ Requirements You may not have noticed, but there are differences in how pip requirements.txt files work and how distutils wants to be told about requirements. The pip way is nicer, because it sure does make it easier to -popuplate a virtualenv for testing, or to just install everything you need. +populate a virtualenv for testing, or to just install everything you need. Duplicating the information, though, is super lame. So PBR will let you keep requirements.txt format files around describing the requirements for -your project, will parse them and split them up approprirately, and inject +your project, will parse them and split them up appropriately, and inject them into the install_requires and/or tests_require and/or dependency_links arguments to setup. Voila! @@ -100,14 +100,14 @@ Usage pbr requires a distribution to use distribute. Your distribution must include a distutils2-like setup.cfg file, and a minimal setup.py script. -A simple sample can be found in pbr s own setup.cfg +A simple sample can be found in pbr's own setup.cfg (it uses its own machinery to install itself):: [metadata] name = pbr author = OpenStack Foundation author-email = openstack-dev@lists.openstack.org - summary = OpenStack's setup automation in a reuable form + summary = OpenStack's setup automation in a reusable form description-file = README license = Apache-2 classifier = diff --git a/doc/source/semver.rst b/doc/source/semver.rst index b22242d6..af60fea7 100644 --- a/doc/source/semver.rst +++ b/doc/source/semver.rst @@ -57,7 +57,7 @@ numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next. Linux Compatible Semantic Versioning is different from Semantic -Versioning in that it does not employ the use of the hypen in ways that +Versioning in that it does not employ the use of the hyphen in ways that are ambiguous when used with or adjacent to software packaged with dpkg or rpm. Instead, it draws from PEP440's approach of indicating pre-releases with leading characters in the version segment.