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.

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?

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, 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?

> 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

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