On Thursday, September 27, 2012 at 11:59 AM, Toshio Kuratomi wrote:
setuptools allows any random string into the versions. Certain strings have special meaning. Unknown strings are lexicographically sorted. Rereading this section of the PEP http://www.python.org/dev/peps/pep-0386/#caveats-of-existing-systems
will give you the background on problems with the setuptools concept. For part of the rationale about .dev, the first paragraph of the rationale is important. setuptools allowed too many things to be allowed into versions. Remembering how the specialcases mix with the lexicographic sorting lead to confusion when some project starts working with non-standard version strings. So one of the goals of PEP 386 was to make a small, discrete number of legal version strings.
No arguments here on the need of this goal.
Keeping that in mind, these are the alpha tags that PEP386 allows: a, b, c, rc, .post, .dev
* 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. * For .post there was a desire to have a tag that sorted after release. Choice of .post for the bikeshed color was not controversial. * For .dev there was a desire to have a tag that sorted before release. Choice of .dev for the bikeshed was debated but in the end it was a bikeshed and we were all very tired of it. I'm not sure at this point who was championing .dev over .pre or similar or what their rationale was.
Yes I've read this, but sadly all it says about the issue really is "I don't remember".
I would be for renaming .dev to .pre[1]_ but I would be against the rest of this proposal. Having one and only one way to spell things was one of the goals of the pep. Having two post release tags that don't already have a defined meaning leads to confusion about what the ordering should be:
dev (in my proposal, and in the way I've seen it used) isn't a post release tag, it is a separate release at the same level as alpha, beta, rc, final, and it's meaning tends to be "this is the in development version of what will become release X.Y", so foo-1.0dev1 means the first development release of what will become foo-1.0, (just like foo-1.0a1 is the first alpha release of what will become foo-1.0). With the current layout (and with your changes to the proposal) there is no good way to have a development version. With the current layout the best approximation you can get is 1.0a1.dev1 (similarly with your changes it would be 1.0a1.pre1). On the surface 1.0a1.dev1 looks like it might be alright, but my issues with it: 1. It's not intuitive (at least not to me, development snapshots have always come before alphas in my mind) 2. Goes against what is currently being used for either no good reason or a yet to be remembered good reason. 3. Requires you to decide ahead of time if you're going to go from dev to alpha, or straight to a beta/candidate/final. (This is something that most small projects don't have set in stone). 4. It's semantics are different, this is a development release of 1.0a1 as opposed to a development release of the 1.0 version. 5. It's just plain ugly. So to be clear my proposal would be: 1.0dev1 < 1.0a1 < 1.0b1 < 1.0c1 < 1.0.pre1 < 1.0 < 1.0.post1 as opposed to the current: 1.0a1 < 1.0b1 < 1.0c1 < 1.0.dev1 < 1.0 < 1.0.post1