python-checkins at python
Nov 24, 2009, 2:20 AM
Post #1 of 1
(118 views)
Permalink
|
|
r76477 - peps/trunk/pep-0386.txt
|
|
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
_______________________________________________
Python-checkins mailing list
Python-checkins [at] python
http://mail.python.org/mailman/listinfo/python-checkins
|
