On Fri, 2005-07-15 at 01:09 -0700, Michael A. Peters wrote:
I know that with shared libraries, it generally is not a good idea
push an update that involves versioning a shared library because the
user may have software their system that is linked against the older
shared library, but is there a general policy about other software?
One of the packages I maintain in Extras is likely to be named as a
sourceforge project of the month. The upstream developer is working
overtime to finish implementing some things before that happens. The
package is gourmet (PyGTK recipe manager) and absolutely nothing depends
upon it - and I'm thinking that when he has these things finished, that
might be a good time to update the package in Extras.
Since it is not a package which is designed to have anything else depend
on it, I'm assuming there is not a problem with a version update in
Extras? Is that the case?
For applications instead of shared libraries there may still be some
artifacts on the system that need updating to a new version. These
would be save files, data stores, and other pieces of persistent data
that may need to be ported from an older version of the package to a new
one. The discussion of whether to package git and cogito a few months
back was one example of this. PostgreSQL's need to dump and restore
between major version upgrades is another.
For gourmet, the questions would probably be -- is the new version
capable of loading the recipes saved in the old version transparently?
If not, is there some way to manually import them? If not, is it a
planned feature for a later date?