TheFlyingDutchman <[EMAIL PROTECTED]> writes:
> On Sep 10, 7:55 pm, "J. Cliff Dyer" <[EMAIL PROTECTED]> wrote:
> > Uh... The 1.0 version is vaporware?
>
> I think not. 42% of it is alive and kicking as we speak.
That's odd. Do you think some similar matchematical relationship
exists between Python version 2.4.4 and 3.0?
You've made the common error of reading a package version as though it
were a single number on a number line. That's not the customary
semantic, though: versions are interpreted as a tuple of distinct
integers.
> When you were developing your Enum module, how did you determine you
> were at the 0.4.2 version as opposed to the 0.7.1 version or the
> 0.9.2 version?
I initially developed at version 0.0, meaning "major level 0, minor
level 0" — i.e., no releases at all.
Then, when the first "alpha" release was ready, I called it version
0.1, meaning "major level 0, minor level 1" — i.e. no major releases
yet, but the first minor release.
Then, a small patch needed to be made, and the resulting release was
version 0.1.1, meaning "major level 0, minor level 1, patch level 1" —
i.e. the first patch to version 0.1.
Eventually some extra features warranted a release of version 0.2,
meaning "major level 0, minor level 2" — i.e. the second minor release
with still no major releases. Implicit in this is "patch level 0",
i.e. no patch-level versions yet; the version could be called 0.2.0
and have the same meaning.
Each dot-separated integer is interpreted as a distinct level,
subordinate to the preceding one:
* Two versions with different major numbers can be expected to be
incompatible.
* If two versions have the same major number, one can expect only
minor feature differences.
* If two versions have the same major and minor number, one can
expect that they differ only in bug fixes or the like.
* Subsequent integers would imply even smaller differences at that
same level if all preceding numbers were the same.
Within a level, subsequent integers imply subsequent release times:
version 0.4.1 can only be released before 0.4.2. However, this is not
true across levels: a hypothetical version 0.2.7 could be released
before *or* after 0.4.2, if the author decides a patch to the (equally
hypothetical) version 0.2.6 is warranted.
As for a putative version 1.0, that will not be released until I
determine the package is functionally complete and warrants a first
major release. Depending on how much changes between now and then, it
may have most, some, or none of the code you see presently in version
0.4.2.
--
\ "That's all very good in practice, but how does it work in |
`\ *theory*?" —Anonymous |
_o__) |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list
