TheFlyingDutchman <zz******@aol.comwrites:
On Sep 10, 7:55 pm, "J. Cliff Dyer" <j...@sdf.lonestar.orgwrote:
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