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 to > 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? -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
