soname change policy proposal

[Michael Schwendt]

On Tue, 27 Jun 2006 11:55:45 +0300, Ville Skyttä wrote:

> >  After the warning one must wait 7 days minimum before the
> >   new version may be build.
> 
> 7 days is too much.  If Core devel is not in the post-last-testX freeze
> before the next release, 1 day is enough.  If Core devel is in that
> freeze, rules for released distro branches apply to devel too.
> Example: according to the current
> http://fedoraproject.org/wiki/Core/Schedule, the final post-last-testX
> freeze would be 23 Aug - 27 Sep.
> 
> For released branches, we assume that a smoothly working compat-foo has
> been already created before the incompatible upgrade is pushed and it
> has stayed in a review for a little while anyway.  So there's no wait
> period, but the notice must be posted to the fedora-maintainers list
> when the new compat package is posted for review, and the review bug
> number is included in that notice.

It is not that easy.

For every scenario in which a packager starts working on a compat-fooX
package for a _release branch_ of a dist, much more must happen prior to
shipping the package.

First of all, and provided that the packager notices the SONAME change (or
ABI/API change) at all, it _must_ be verified that existing software in
the release branch can still be (re-)built with either compat-fooX-devel
or the new foo-devel. This step is mandatory. It requires review, testing,
and approval.

I see phrases like "quick and dirty" and would prefer if it were called
"painstakinly and safe" instead. Any API break in a release branch may
prevent the next security fix from being built quickly and painlessly.

Further, packagers, especially library packagers, ought to become familiar
with what in the distribution depends on them. I'm not convinced that
maintainers-list is the right forum where to address package owners and
where to warn about ABI/API breakage.  I'd rather see packagers use
bugzilla or private mail to announce and talk about a change in SONAMEs
before agreeing on introducing the changes. There ought to be coordination
and collaboration. Application packagers could be the reviewers of library
packagers' review requests.

> > 2) When a compat package must be created there are 2 possible scenarios.
> >   When the soname is changed the ABI is changed, however sometimes the
> >   API is not changed or kept compatible. When the API is not changed then
> >   the compat package must not come with a -devel subpackage and the quick
> >   and dirty method described below may be used. When the API is changed
> >   the compat package is concidered a new package and must go through the
> >   review process as usual, in this case the compat-package must come with
> >   a -devel subpackage.
> 
> All compat-* need to go through a review.

But of course!