On Wed, Feb 6, 2013 at 12:15 AM, <a.cava...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
