[Distutils] Simple idea to resolve versioning problems

[Cliff Wells]

On Tue, 2008-04-15 at 13:01 +1200, Greg Ewing wrote:
> David Cournapeau wrote:
> > what is needed is a stable API for the used packages.
> 
> That's a nice ideal to aim for, but it's only achievable
> for old and mature packages.

I don't think so.  It requires vigil on the part of the maintainer, but
even young packages can have a sane versioning policy.

> One could change the package name every time the API
> changes, but then *any* change to the API would make the
> package unusable by apps expecting an earlier version,
> even if the new API is backwards compatible.
> 
> Having said that, I just realised you can address that
> by putting in symlinks for the previous versions.

I don't think that's supported on Windows.

> So, I hereby propose the following convention for naming
> of Python packages:
> 
>    packagename_<version>

I don't know that this is an actual replacement for setuptools (rather a
way to simplify setuptools), but I like the idea in general. However
what I'd rather see is:

    site-packages/package/major_version

It would keep the site-packages directory from becoming a giant mess and
be more portable.

> where <version> is a number or other identifier that is
> changed whenever the API changes in any way.

I think the convention is major.minor where minor releases are
backwards-compatible and major releases aren't expected to be (but might
be).  
Sometimes this is confusing as projects will do a major version release
due to say, major code-refactoring that doesn't necessarily affect the
API, so the API "version" isn't necessarily reflected in the package
version.  On the other hand, not using the higher version certainly
won't break existing code either, so it's rather moot whether you
*could* use the higher versioned software if your concern is not
breaking an existing system.  

Regards,
Cliff