On Thu, Sep 27, 2012 at 01:46:25PM -0400, Éric Araujo wrote: > Le 27/09/2012 11:59, Toshio Kuratomi a écrit : > > * a, b, c, and rc are the typical alpha beta release candidate tags. We > > debated whether to allow the single letter versions or the long versions > > "alpha", "beta", "rc". In the end, which set of tags was used was > > a bikeshed argument so it was chosen by PEP-author decree. I personally > > felt that having both "c" and "rc" was counter to the goals of the PEP but > > we at least agreed that "rc" would intuitively sort after "c" so it wasn't > > as bad as having both "alpha" and "a" where there would be no intuitively > > correct sorting. > > Well, c and rc should really compare equal in my opinion. > That would be a bad thing. What do you do in the face of a project releasing:
foo-1.0c1 foo-1.0rc1 Does your tool get to download either one of those depending on who coded it, the timestamp for the upload, or input from the RNG? And saying that the foo project maintainers shouldn't do that because they're semantically the same is well ad good but in practice people do things that are wrong all the time. With a single version string inside of a package we can provide functions that can validate whether the version is correct or not as part of using the versions in the library to mitigate that. We cannot do the same thing with version strings from two separate releases of the package because where those releases are stored is site/project specific. Documenting that even though c and rc are menat to be semantically the same they should always sort "c" followed by "rc" protects you from these problems. -Toshio
pgpC9JqWUSd8H.pgp
Description: PGP signature
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
