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 protected] wrote: > On Wed, Feb 6, 2013 at 12:15 AM, <a.cav > [email protected]> 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@g > mail.com | Brisbane, Australia > > _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
