[Python-checkins] r76477 - peps/trunk/pep-0386.txt

[tarek.ziade]

Author: tarek.ziade
Date: Tue Nov 24 10:24:35 2009
New Revision: 76477

Log:
more motivation text and removed trailing space

Modified:
   peps/trunk/pep-0386.txt

Modified: peps/trunk/pep-0386.txt
==============================================================================
--- peps/trunk/pep-0386.txt	(original)
+++ peps/trunk/pep-0386.txt	Tue Nov 24 10:24:35 2009
@@ -12,7 +12,7 @@
 Abstract
 ========
 
-This PEP proposes the inclusion of a new version comparison system in 
+This PEP proposes the inclusion of a new version comparison system in
 Distutils.
 
 
@@ -25,7 +25,7 @@
 
 These changes are located in PEP 345 [#pep345]_.
 
-The ``Requires-Dist`` field will allow a package to define a dependency on 
+The ``Requires-Dist`` field will allow a package to define a dependency on
 another package and optionally restrict this dependency to a set of
 compatible versions, so one may write::
 
@@ -34,6 +34,10 @@
 This means that the distribution requires ``zope.interface``, as long as its
 version is superior to ``3.5.0``.
 
+This also means that Python projects will need to follow the same convention
+than the tool that will be used to install them, so they are able to compare
+versions.
+
 That's why Distutils needs to provide a robust standard and reference
 version scheme, and an API to provide version comparisons.
 
@@ -48,7 +52,7 @@
 
 In Python there are no real restriction yet on how a project should manage
 its versions, and how they should be incremented. They are no standard
-either, even if they are a few conventions widely used, like having a major 
+either, even if they are a few conventions widely used, like having a major
 and a minor revision (1.1, 1.2, etc.).
 
 Developers are free to put in the `version` meta-data of their package any
@@ -62,7 +66,7 @@
 for OS packagers, that need to have stricter conventions. The worst case is
 when a packager is unable to easily compare the versions he needs to package.
 
-For people that want to go further and use a tool to manage their version 
+For people that want to go further and use a tool to manage their version
 numbers, the two major ones are:
 
 - The current Distutils system [#distutils]_
@@ -71,7 +75,7 @@
 Distutils
 ---------
 
-Distutils currently provides a `StrictVersion` and a `LooseVersion` class 
+Distutils currently provides a `StrictVersion` and a `LooseVersion` class
 that can be used to manage versions.
 
 The `LooseVersion` class is quite lax. From Distutils doc::
@@ -280,7 +284,7 @@
 The trailing ``.dev123`` is for pre-releases. The ``.post123`` is for
 post-releases -- which apparently is used by a number of projects out there
 (e.g. Twisted [#twisted]_). For example *after* a ``1.2.0`` release there might
-be a ``1.2.0-r678`` release. We used ``post`` instead of ``r`` because the 
+be a ``1.2.0-r678`` release. We used ``post`` instead of ``r`` because the
 ``r`` is ambiguous as to whether it indicates a pre- or post-release.
 
 Last, ``.post456.dev34`` indicates a dev marker for a post release, that sorts
@@ -344,10 +348,10 @@
 to get an equivalent (or close) rational version from this function.
 
 This does a number of simple normalizations to the given string, based
-on observation of versions currently in use on PyPI. Given a dump of those 
+on observation of versions currently in use on PyPI. Given a dump of those
 version during PyCon 2009, 4287 of them:
 
-- 2312 (53.93%) match RationalVersion without change with the automatic 
+- 2312 (53.93%) match RationalVersion without change with the automatic
   suggestion
 - 3474 (81.04%) match when using this suggestion method
 
@@ -391,7 +395,7 @@
 Acknowledgments
 ===============
 
-Trent Mick, Matthias Klose, Phillip Eby, and many people at Pycon and 
+Trent Mick, Matthias Klose, Phillip Eby, and many people at Pycon and
 Distutils-SIG.
 
 Copyright