Donald Stufft committed e3e473e

Date based releases are not special, they are just integers

  • Participants
  • Parent commits 80be84f

Comments (0)

Files changed (1)

    form to ``X.Y.0`` when comparing it to any release segment that includes
    three components.
-Date based release segments are also permitted, and are treated differently
-in some cases when used in version specifiers. Any version identifier where
-the leading component in the release segment is greater than or equal to
-``1980`` is considered to be a date based release.
-An example of a date based release scheme using the year and month of the
+Date based release segments are also permitted. An example of a date based
+release scheme using the year and month of the release::
 `Version scheme`_. Local version identifiers are NOT permitted in this
 version specifier.
-Automated tools SHOULD report an error when this operator is used in
-conjunction with a date based version identifier, as it assumes the use
-of semantic API versioning.
 For a given release identifier ``V.N``, the compatible release clause is
 approximately equivalent to the pair of comparison clauses::
 a couple of projects with version identifiers differing only in a
 trailing ``\n`` character were found on PyPI.
-The exclusion of major release numbers that look like dates was implied
-by the overall text of PEP 386, but not clear in the definition of the
-version scheme. This exclusion has been made clear in the definition of
-the release component.
 `Appendix A` shows detailed results of an analysis of PyPI distribution
 version information, as collected on 19th February, 2013. This analysis
 compares the behaviour of the explicitly ordered version schemes defined in
 like to be able to migrate to the new metadata standards without changing
-The approach now adopted in the PEP is to:
-* consider a leading release segment component greater than or equal to
-  ``1980`` to denote a "date based release"
-* recommend reporting an error if ``~=`` is used with a date based release
-This approach means that date based version identifiers should "just work"
-for ``pytz`` and any other projects with stable APIs, and at least be usable
-(through the use of appropriate version specifiers on the consumer side) for
-projects with less stable APIs.
 Adding version epochs