soname change policy proposal

[Hans de Goede]

Hi all,

I've been thinking about this for a while and I think its time for a 
brain dump, so here is a first shot at a soname change policy:

1) When a package update would cause an soname change then a compat
  package with the old libraries must be provided for all release repos,
  that is for all repos except devel.
1a) This compat package must be successfully build before a build of
  the update causing the change may be requested.
1b) If an update causing a soname change will only be build for devel
  a compat package is not mandatory. In this case however other packagers
  must be warned, with the warning containing a way for them to get the
  new version. After the warning one must wait 7 days minimum before the
  new version may be build.

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.
2a) If there is:
  -a small incompatible API change which can _not_ create silent (not
   detected by the compiler) breakage, and
  -other packages using the package can easily be fixed to compile and
   run with the new version, then
  The quick and dirty method may also be used. An example of this would
  be a function getting an additional parameter which can be set to 0 to
  get the old behaviour. In this case however other packagers must be
  warned and the warning must include a description what changes are
  necessary and howto make these changes.
2b) When a compat-xxx-devel package is created this package must
  be parallel installable with the real -devel package. In cases where
  this is very hard to achieve in a good way an exception to this rule
  may be made by the reviewer.

3) The quick and dirty method consists of:
  * renaming the spec file and "Name: " field to:
     compat-<oldname><majorversion>
   Where <majorversion> is the for the soname relevant
   part of the version without the dots. For example if a new SDL 1.3
   would be released then the EVR of the compat package would be
   compat-SDL12-1.2.10-1, and thus _not_ compat-SDL1210-1.2.10-1
   because the .10 is not relevant for the soname since SDL-1.2.0 had
   the same soname.
  * Remove the -devel subpackage
  * Add the files from %files devel to %files with %exclude in front.
  * Add a Changelog entry describing the changes and the reason for this.
  * Create a Review request for this and approve it yourself in order to
   keep Chris' scripts happy. This also makes other other FE contributers
   aware of what your doing through the review-list.
  * Import, request branches etc.


Well thats it I hope verybody likes it and FESco can vote on this 
sometime soon :)  Notice that I have no direct interest in this, it is 
just something I've been thinking about after the directfb discussion.

Regards,

Hans