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?
The project is under fairly rapid development but I don't intend to package every little update simply because most of them don't add anything worth an update imho, but I think the update he is planning (after testing) is will be worth pushing an update.
On Fri, 15 Jul 2005 01:09:01 -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?
With "versioning a shared library" here you mean a change in SONAME?
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?
If your package is the only one which accesses the shared libs, no problem. This is most certainly the case when the package doesn't provide a public API and if no other package implements an API either. Hence: no dependencies in Extras => don't worry about upgrades.
On Fri, 2005-07-15 at 10:45 +0200, Michael Schwendt wrote:
On Fri, 15 Jul 2005 01:09:01 -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?
With "versioning a shared library" here you mean a change in SONAME?
yes
If your package is the only one which accesses the shared libs, no problem. This is most certainly the case when the package doesn't provide a public API and if no other package implements an API either. Hence: no dependencies in Extras => don't worry about upgrades.
OK - cool
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
packaging@lists.fedoraproject.org
-
Michael A. Peters -
Michael Schwendt -
Toshio Kuratomi