Op 05-07-11 09:51, "Martin v. Löwis" schreef:
I *personally* think you are exaggerating your case. If you are using
a package, avoid sticking to a specific version of the software, and
instead write the package in a way that will work with many versions
of the library. If the library is too unstable, don't use it at all.
If the library has an incompatible change, report it as a bug; if
the author can bring convincing arguments why there must be that
change, cope with it.
IOW, just don't use old versions when newer versions are available
and maintained.
In my case, usually when I start a new (client) project for which I need
package foo I use the latest release 1.0. The problems is that most of
the time I do not know yet if a new version (whether that is going to be
1.0.1, 1.1 or 2.0) is going to cause backwards compatibility problems.
And this may be the first time I am using package foo so I do not know
yet if this author prefers to actively delete old versions.
FWIW, I am using a pypi mirror created with collective.eggproxy as an
index so that packages I use in my buildouts are available on that
mirror (so only actually used packages are mirrored). This shields me
at least partially from these problems.
Cheers,
--
Maurits van Rees
Web App Programmer at Zest Software: http://zestsoftware.nl
Personal website: http://maurits.vanrees.org/
_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig
