On Fri, Jun 5, 2009 at 4:59 PM, Paul Moore
2009/6/5 Tarek Ziadé
: No one will force people to use the one we are defining, like no one forced people to use StrictVersion or LooseVersion.
But it's being defined via a PEP (rather than hidden in the code, as with Strict/LooseVsersion) so it has a higher level of visibility and authoritativeness. So it should be held to higher standards. Maybe I won't be forced to use it, but I suspect I will be *expected* to. And quite possibly disadvantaged if I don't.
Probably so yes, if you use the install_requires field PEP 345 introduces, where you will define dependencies with their versions. And if you don't use dev. flags for example, you will have to deal with them if they are present in other projects you depend on. It's a real need. We could use the setuptools standard here, because it's the de-facto standard for this metadata today, (and that's what I have proposed first during the Pycon sessions), but some use cases were raised and the work+proposal you see in PEP 386 followed. I see only advantages on having a strict, well-documented standard for versions numbers., that we know is good enough for non-python packagers. Let's see what is going to come out of the other threads (with Phillip and Trent on the edge case). I do believe we can have something that'll reach consensus at some point when these edge cases are resolved, because the whole thing will probably work with much simpler cases like you have shown; At least I hope we all agree that : 2009.05.12 is not a good version number, and that we all want a major/minor scheme. Regards Tarek