On Sat, Mar 2, 2013 at 5:04 PM, Diego Biurrun <[email protected]> wrote:
> On Sat, Mar 02, 2013 at 12:46:32PM +0100, Reinhard Tartler wrote:
>>
>> --- a/doc/developer.texi
>> +++ b/doc/developer.texi
>> @@ -547,4 +547,107 @@ why the expected result changed.
>> +Note that we promise to our users that the resulting shared libraries
>> +never break programs that have been @strong{compiled} against previous
>> +versions of @strong{Libav} in any case! However, since from time to
>> +time we do change APIs in our libraries that may require adaptations to
>> +applications, special care must be taken to not break executables that
>> +have been compiled against earlier versions of libav. The necessary
>> +steps are best discussed on the @strong{libav-devel} mailing list and
>> +may involve bumping the major version of the library or adjustments to
>> +the symbol versioning file.
>
> I'm still not too happy with this paragraph. How about something along
> the lines of
>
> Our releases come with certain API and ABI stability guarantees. Point
> releases must never break programs compiled against previous versions
> of our libraries from the same release branch.
>
> However, from time to time, we do make API changes that require adaptation
> in applications. Such changes are only allowed in major releases and will
> require further steps such as bumping library version numbers and/or
> adjustments to the symbol versioning file.
TBH, I fail to see the practical differences between the two wordings.
I guess that you fear that someone may misinterpret how we are
maintaining API/ABI stability, but I fail to see how your wording
addresses this. Just to be safe, can you please elaborate on your
concerns?
>
>> +@item
>> + Retains both source code and binary compatibility with previous
>
> I'd say s/code//, but whatever you prefer.
I'd prefer to keep it in to emphasize that these are two seperate
things, and that they are equally important.
--
regards,
Reinhard
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
