[Distutils] PEP 426, round 733 ;)

[Nick Coghlan]

On Wed, Feb 6, 2013 at 12:15 AM,  <a.cavallo at cavallinux.eu> wrote:
>
> Not quite correct: 1.1.x and 1.2.x are two separate branches in Django.
>
> So along the 1.1.x branch the timestamp identifies what comes first and after.
> Think of a plane where the coordinates are the timestamp and the branch: to
> compare you need fix one of the two (the branch in this case).
>
> BTW the fact that in your mind 1.2.x comes later than 1.1.x is because you're
> already "sorting" them adding a semantic value built into the version *LABEL*.
> For a counter example how would compare then 1.x and 2.x: is 2.x continuing along
> 1.x or is it a completely unrelated source? And that *cannot* be captured.
>
> My point in suggesting a timestamp is because it freeze the repository state in a
> unique way: scms have already that concept built into it (even distributed scm
> have that!).

The version scheme is not going to change. The point of PEP 386 was,
to a very large extent, to define a scheme that *existing PyPI
projects* either already comply with, or will require only minor
cosmetic changes to comply with (such as inserting an extra period to
turn X.YdevN into X.Y.devN).

In other words, the intent was not to invent a new versioning scheme,
but merely to formalise a subset of one that already existed in the
wild. One of the main goals of PEP 426 is to *lower* barriers to
adoption for the new metadata standard, not to create new ones -
throwing away the work that went into creating the PEP 386 versioning
scheme would be a foolish waste of time and energy. Even the problem
with the sorting of dev releases was enough to hinder adoption of v1.2
of the metadata - there's no way we're going to try to enforce a more
radical shift in the community approaches versioning. We already know
the most likely outcome of such an effort: people will simply stick
with v1.1 of the metadata scheme and continuing to use the existing
packaging tools, as migrating to the new ones would require a whole
lot pointless busywork to redesign their build processes and
workflows.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia