I respectfully disagree, for what it matters I will ignore the whole stuff.
These PEPs have been around for ages. And I supsect they will be around until the end of times. Or until when somebody will explain if X.Y.devN comes before of after X.Y.N...
On Tue 05/02/13 15:44, "Nick Coghlan" email@example.com wrote:
On Wed, Feb 6, 2013 at 12:15 AM, <a.cav firstname.lastname@example.org> 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.
-- Nick Coghlan | ncoghlan@g mail.com | Brisbane, Australia
On Tue, Feb 5, 2013 at 10:53 AM, Donald Stufft email@example.com wrote:
On Tuesday, February 5, 2013 at 10:49 AM, firstname.lastname@example.org wrote:
Or until when somebody will explain if X.Y.devN comes before of after X.Y.N...
Which is explained in the PEP pretty clearly I thought. But if you're still not sure there were lengthy discussions on this very mailing list that led to that decision. For what it's worth, there were people who argued the opposite too, but eventually it seems like a consensus was reached.