On Sat, Nov 28, 2009 at 4:00 AM, P.J. Eby <[email protected]> wrote: > At 12:26 PM 11/28/2009 +1100, Ben Finney wrote: >> >> I think you're reading a proposal that I didn't write. > > Are you not the person who's proposed using simple alphanumeric strings for > version comparison? > >> My understanding of PEP 386 is that it *isn't* about asking Python >> developers to change how they work. Is that not right? > > Asking them to generate alternative versioning schemes, without the ability > to use pre-release versions (e.g. alpha, beta, etc.) would most certainly be > a change from the status quo. > >> Moreover, what is a standard for if not for encouraging people to follow >> it for the benefit of many? > > Usually, they get something in trade. Supporting WSGI means you get to use > WSGI apps, or run on a WSGI server, for example. So, cost and benefit are > balanced. > > In contrast, a popular Python library or app will get packaged if somebody > wants it, and not if they don't. There isn't a lot of incentive for a > developer to do something different, solely for the sake of the packager... > which is probably why things are the way they are now. > > If, on the other hand, there's some positive benefit being offered (e.g. a > new tool that makes life easier for them or perhaps their users), then there > might be some incentive to learn a new way of coding versions. But without > such an incentive, who wants to learn some new way to encode prerelease > versions? > > This is why I've argued for keeping a scheme in 386 that can mechanically > translate most existing versioning schemes found in the wild: it means that > most people won't have to do a thing, as tool builders can just use > suggest_version().
Yes, this function can be used internally, and that was a good idea to have that function. But as soon as it is used inside a public package manager, like pip or setuptools or distribute, I expect this function to raise some kind of warning so the developers knows its version doesn't meet the public, documented standard. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
