On Mon, Oct 15, 2012 at 06:01:17PM +0200, John Stebbins wrote: > On 10/15/2012 05:38 PM, Diego Biurrun wrote: > > On Sun, Oct 14, 2012 at 05:41:03PM +0200, John Stebbins wrote: > >> On 10/14/2012 05:14 PM, Luca Barbato wrote: > >>> On 10/14/2012 04:52 PM, John Stebbins wrote: > >>>> + uint8_t forced; > >>> why uint8_t ? I guess it would require a version bump btw. > >>> > >>> In itself looks a good feature (and probably the players would enjoy > >>> having this information) > >> Is the version number bump something I should do in the patch, or do you > >> prefer handling that yourselves? > > It's preferable you do it lest it be forgotten. > > Ok. I'm unfamiliar with how libav versioning works. Can you educate me > or point me to the write document? I.e. what file and what define gets > changed in this case?
http://www.libav.org/developer.html#Development-Policy 16. Remember to check if you need to bump versions for the specific libav parts (libavutil, libavcodec, libavformat) you are changing. You need to change the version integer. Incrementing the first component means no backward compatibility to previous versions (e.g. removal of a function from the public API). Incrementing the second component means backward compatible change (e.g. addition of a function to the public API or extension of an existing data structure). Incrementing the third component means a noteworthy binary compatible change (e.g. encoder bug fix that matters for the decoder). In your case I think bumping the minor number should be appropriate. Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
