[Distutils] PEP 426, round 733 ;)

[a.cavallo at cavallinux.eu]

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" ncoghlan at gmail.com wrote:
> On Wed, Feb 6, 2013 at 12:15 AM,  <a.cav
> allo 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 g
> mail.com   |   Brisbane, Australia
> 
>