[spambayes-dev] RE: Version Data

[Kenny Pitt]

Tony Meyer wrote:
> [Kenny, way back in February]
>> My proposal is that all apps share the source release version
>> as their primary version number.  The shared release version
>> would consist of the following parts:
>> 
>> * A major/minor version number (1.0)
>> * A release number that would increment for each release.  If
>> alpha9 is our ninth release then the release number would be 9,
>> but it would increment to 10 for beta1.  The release number could
>> be reset to 1 when we move on to 1.1 development (although it
>> wouldn't have to be).  The purpose of this is to give us a three-part
>> version number major.minor.release that is always increasing.
>> * A string representation of the version ("1.0a9" or "1.0b1").  The
>> binary major.minor.release version would be used for version check
>> comparisons, but this string representation is what would be
>> visible to the user.
>> * A release date ("Feb 2004")
> 
> This all sounds pretty good to me - I think we might as well make the
> bits all separate, e.g:
> 
>   {
>     'major': 1,
>     'minor': 1,
>     'release': 0,
>     'prerelease': 1,  # i.e. first alpha release
>     'date': 'January 2005',
>     'download_page': 'http://spambayes.sourceforge.net/windows.html',
>     'release_notes_page': 'http://whatever',
>     'short_string': spambayes.__version__,
>     'long_string': "SpamBayes version
> %(major)d.%(minor)d.%(release)d.%(prerelease)d (%(date)s)",
>   }
> 
> (short_string and long_string could just be functions, of course).
> 
>> In addition to the shared version info, the engine and each
>> application would have a separate "revision number" that we would
>> increment during development to track changes specific to that app.
> 
> I've completely gone off the idea of having anything separate for the
> different apps.  One release for them all is much simpler.

As long as we have only one version, I think a lot of this could be stored
once in the main "spambayes" package __init__.py file and eliminate all the
duplication.  We could put the following values into __init__.py:

"""
__version__ = "1.1a1"
__date__ = "January 2005"
"""

distutils has a StrictVersion class which parses a version string similar to
what we use with versions of the form "1.0", "1.0.1", "1.1a1", etc.  It also
provides a compare function for comparing two version numbers, which would
be great to replace the float version number stuff we're currently using for
update checks.  It doesn't support the "1.0rc2" release candidate format,
but that shouldn't take more than a couple of minutes to add.

For consistency, I think it would be good to provide the separate components
of the version in the format of the sys.version_info tuple.  This could be
incorporated into the Version class along with the function to format the
long form of the version.

>From what I understand, we're free to put any custom metadata we want in the
__init__.py file, so we could even include the download and release notes
URLs there.

-- 
Kenny Pitt