[FFmpeg-devel] [RFC] Internal API updating policy
Stefano Sabatini
stefano.sabatini-lala
Sun May 16 19:59:30 CEST 2010
On date Sunday 2010-05-16 01:50:25 +0300, Uoti Urpala encoded:
> On Sun, 2010-05-16 at 00:25 +0200, Stefano Sabatini wrote:
> > On date Sunday 2010-05-16 00:21:05 +0300, Uoti Urpala encoded:
> > > This is the part that of your suggested rules that can fail. Suppose
> > > lavf major version 1 already uses that symbol, and current lavf version
> > > is 2. Both use lavc version 1. Having both lavf1 and lavf2 installed
> > > simultaneously must be possible. You can't update lavf1 because there
> > > are no newer versions of it, and it would be incompatible with the
> > > changed lavc, so it must depend on lavc1 < X.Y.Z. OTOH lavf would depend
> > > on lavc1 >= X.Y.Z. Therefore the version of lavc1 installed would need
> > > to satisfy both that the version is < X.Y.Z and >= X.Y.Z. This is
> > > impossible, so package version constraints aren't enough and a major
> > > lavc version bump is required.
> >
> > That's because you cannot have two different shared libraries with the
> > same major right? If it would be possible to keep two distinct
> > libavcodecX.Y.Z and libavcodecX.Y.Z' and make libavformatN and
> > libavformatM link against the right one
>
> It's not.
>
> > then the problem wouldn't exist, right?
>
> Depends on how things would be if they weren't like they are now...
>
>
> > Well having such a system should help at least for distribution when
> > just one version of each shared library needs to be present, at least
>
> It doesn't help much in that case, and that case isn't enough. Packaging
> the next major library version must be possible without switching every
> depending library and application in a single atomic transition.
The solution would be to use the same policy for API symbols, renames
should preserve the old symbols (e.g. by adding a suffix to the new
symbols) *if* the internal API symbol is used by another (internal)
library.
Same for functions, when a function beloning to the internal API *and*
used by another library is renamed or its signature is changed, the
old variant should be preserved, and eventually dropped at the next
major bump.
This should be completely safe and should allow the scenario you
described.
I suggest anyway to update micro when adding new internal symbols and
when adding internal dependencies.
See patch attached.
Regards.
--
FFmpeg = Furious and Fierce Moronic Powerful Enchanting Goblin
More information about the ffmpeg-devel
mailing list