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!). On Tue 05/02/13 13:54, "Donald Stufft" donald.stu...@gmail.com wrote: > On Tuesday, February 5, 2013 at 5:35 AM, a.cava...@cavallinux.eu > wrote: > Ideally it would be something that connects to the source revision > number (as in > subversion) or the integral id or even a timestamp (that's what an > exported > version must be). > Timestamp or reversion number is not overall useful number for a > version and > here's why: Django (for example) maintains older versions for a set > period of time, > If you do it via timestamps than 1.1.1 which happens to be released > after 1.2.0 (because > of a security issue or glaring bug) will be considered "newer". > Handwaving the problem > away with a source revision number or timestamp ignores a fundamental > property > of a version. > > _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
