[SciPy-dev] version numbers.

eric eric at scipy.org
Mon Feb 18 23:12:59 CST 2002


Hey crew,

On the version numbers, I now have an opinion. :-)  Nothing like an implementation to get ones attention.

Since we're working on the 0.2 release of SciPy, I think the version number should look something like this:

   0.2.xxxxxx

Where xxx can be replaced by anything we want from the CVS.  I was looking at the version number of SciPy and noticed it was already up to 0.5.xxx.  After a moment of euphoria (what will 0.5 look like anyway?), I'm back to reality now...

I like the fact that Pearu's is grabbing numbers based on CVS changes, but I'd like to move them to the end of the version number.  What would you think of the first two (or maybe even three as Python uses like 2.1.1) entries in the version number tied to something human specified instead of the CVS?  This will lead to very long version numbers, but most people can ignore anything after the first three.

So, here are my proposed modification to Pearu's versions:

       <major>.<minor>.<micro>-<release_level>-<cvs-minor>.<cvs-micro>.<serial>

<major>, <minor>, and <micro> are all human specified and won't change that often (where should we store these anyway?).  <cvs-minor> and <cvs-micro> have the some meaning as Pearu's original <minor> and <micro> numbers.  I've included the doc-string from his code at the bottom that has more complete explanations of each.

One other question -- do we need all three of these -- <cvs-minor>.<cvs-micro>.<serial> -- or could they combined into one CVS based number?  If the 3 separate numbers are valuable in their own rights, I'm happy to keep them around.  But if we're just looking for uniqueness, then we could lump them all together.

Thoughts?

thanks,
eric

Here is the doc-string from the current version number calculator:

    Return version string calculated from CVS/Entries file(s) starting
    at <path>. If the version information is different from the one
    found in the <path>/__version__.py file, update_version updates
    the file automatically. The version information will be always
    increasing in time.
    If CVS tree does not exist (e.g. as in distribution packages),
    return the version string found from  <path>/__version__.py.
    If no version information is available, return None.

    Default version string is in the form

      <major>.<minor>.<micro>-<release_level>-<serial>

    The items have the following meanings:

      serial - shows cumulative changes in all files in the CVS
               repository
      micro  - a number that is equivalent to the number of files
      minor  - indicates the changes in micro value (files are added
               or removed)
      release_level - is alpha, beta, canditate, or final
      major  - indicates changes in release_level.

--
Eric Jones <eric at enthought.com>
Enthought, Inc. [www.enthought.com and www.scipy.org]
(512) 536-1057

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/scipy-dev/attachments/20020219/3271130f/attachment.html 


More information about the Scipy-dev mailing list