[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

[Robert Swain]

2009/1/22 Stefano Sabatini <stefano.sabatini-lala at poste.it>:
> On date Wednesday 2009-01-21 19:13:26 -0800, Mike Melanson encoded:
>> Peter Ross wrote:
>> > Hi,
>> >
>> > Last week the third Foundations of Open Media Software Workshop (FOMS 2009)
>> > was held in Hobart, Australia. I attended to wave the FFmpeg & Xvid flag.
>> > A number of concerns about FFmpeg were spoken of during the workshop, so
>> > about half an hour was spent collating them. A dump of my notes is provided
>> > below with a paraphrasing of the hurt statements.
> [...]
>> > 2. CONCERN: API stability
>> >    "The FFmpeg API keeps changing..."
>> >
>> >    API is not backwards compatible between major API version bumps. Stuff
>> >    gets deprecated, API behaviour changes.
>> >
>> >    This makes upgrading the libav* packages on a distribution difficult,
>> >    because often the application also needs to be upgraded.
>> >
>> >    As long as new codecs, containers and concepts are being added to FFmpeg,
>> >    the API will continue to change.
>> >
>> >    Ensuring backwards compatibility is a lot of work. There are perhaps more
>> >    important things to be concerned about.
>> >
>> >    Do we need a mechanism to inform users of FFmpeg about API changes?
>
> It's worthy to note that backward compatibility breaker API changes
> only happen at major bumps, which are not so frequent (I can remember
> just two (lavc and lavf) in two years of activity on this project).
>
> We could have a changelog with all the API changes (e.g. functions
> deleted, functions added) that we could compile every time we modify
> it.
>
> This way the user will be able to understand with O(n) steps which are
> the changes to be performed on its own code when it has to switch from
> libav* from version X -> Y.
>
>> Releases should at least partially obviate the problem.

I think this is an excellent suggestion by Stefano. I always envisaged
this happening when we made releases but if API changes only occur
when bumping the major version number, I think it would be wise to
document any API changes in some file _at commit time_ as Stefano
suggests, underneath the next major API number.

I really think this should be a rule that is enforced and kept on top
of from now on. Then when people claim that the FFmpeg library APIs
are always changing, we can point them to some evidence of how much it
changes and what they need to do.

There are other things we should probably pick up on and consider as
new mandatory practises in this thread too.

Best Regards,
Rob