On Thu, Sep 27, 2012 at 02:42:50PM -0400, Donald Stufft wrote:
On Thursday, September 27, 2012 at 2:03 PM, Toshio Kuratomi wrote:
That's your preference, not capability. I'd also say you should use 1.0.post1 rather than 1.0a1pre1.
So how do you encode the very first development release then if you're using post?
Took me a couple readings but I think you mean: I start a project this morning. I make a snapshot this afternoon. What should the version be? Using the current versioning scheme, I'd personally do: 0.dev1 By the time I get to an alpha release, we're going to have a version number (for instance, 0.1). So an initial version on the first day of 0 is fine: 0.dev1 < 0.1a1 < [...] < 0.1 /me has seen this in the wild as well... not just in my theoretical mind :-)
Can you point me towards somewhere where their conceptual release cycle is
Final -> Dev -> Alpha -> Beta -> RC
or
Alpha -> Beta -> RC -> Final -> Dev
I'm not sure what you're asking here. All projects change code and release it. The changes may get released as something "official"-y like an alpha, a beta, an rc, or a final. They may also be released like a snapshot. Those snapshots can be taken from any point on the timeline against any release. Trying to say that "snapshots only happen before alpha beta rc" or "snapshots only happen after alpha beta rc" doesn't map to what people in the real world are doing. I think we both get to this same place down below, though, so I'll skip down to there.
This also makes sense to me in my particular use case, and it sounds like it makes sense in yours? My main concern is that shifting 0.1dev1 from sorting before alpha/beta/candidate to sorting after them is going to cause headaches. So perhaps a better proposal would be to allow .dev at any level (as it does currently), but dictate that .dev sorts first at whatever level it occurs at (which is what setuptools does). This fixes my major problem of getting bitten because setuptools and PEP386 treat "1.0dev1" differently while still giving people the ability to do "1.0a1.dev1". The major drawback being that you can't do a "dev/pre" release between an rc and a final, but as pkg_resources doesn't currently allow for that I would think that isn't a huge concern? That might solve the use case for both sides?
If we're just changing the position of X.Y.preN from this: 0.1 < 0.1.post1 < 0.2a1.pre1 < 0.2a1 < 0.2a1.post1 < 0.2b1 < 0.2pre1 < 0.2 to this: 0.1 < 0.1.post1 < 0.2pre1 < 0.2a1.pre1 < 0.2a1 < 0.2a1.post1 < 0.2b1 < 0.2 then that works perfectly fine for me. To put out a snapshot between rc and final, I'd do 0.2rc1.post1 so not having a pre/dev in there doesn't bother me. However, now that you mention it, ISTR that this is the way that it was originally and the lack of pre/dev in that position did bother another (set of?) the PEP authors enough that it was changed. For me, switching the search order of that particular piece is a bikeshed so I seem to have reallocated the memory for storing the arguments made in favor of shifting it to the current position :-) -Toshio