[Fedora-packaging] updating versions policy

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20050808/4745e837/attachment.sig>