Version numbering (was: Enum class with ToString functionality)

[Ben Finney]

TheFlyingDutchman <zzbbaadd at aol.com> writes:

> On Sep 10, 7:55 pm, "J. Cliff Dyer" <j... at sdf.lonestar.org> 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