[FFmpeg-devel] [PATCH 1/2] avutil/version: Mention similarities and differences to semver
jamrial at gmail.com
Tue Aug 9 00:11:52 EEST 2016
On 8/8/2016 5:09 PM, Michael Niedermayer wrote:
> On Mon, Aug 08, 2016 at 06:32:23PM +0200, Carl Eugen Hoyos wrote:
>> 2016-08-06 12:52 GMT+02:00 Michael Niedermayer <michael at niedermayer.cc>:
>>> QUESTION: is this the best place for this ?
>>> Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
>>> libavutil/version.h | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>> diff --git a/libavutil/version.h b/libavutil/version.h
>>> index b2dffb7..7692def 100644
>>> --- a/libavutil/version.h
>>> +++ b/libavutil/version.h
>>> @@ -35,6 +35,12 @@
>>> * Useful to check and match library version in order to maintain
>>> * backward compatibility.
>> This is at least not a bad place imo.
>>> + * The FFmpeg libraries follow a versioning sheme very similar to
>>> + * Semantic Versioning (http://semver.org/)
>>> + * The difference is that the component called PATCH is called MICRO in FFmpeg
>>> + * and its value is reset to 100 instead of 0 to keep it above or equal to 100.
>>> + * Also we do not increase MICRO for every bugfix or change.
>> But we want / should increase MICRO for every bugfix and every functional
>> change, no?
> i would say, yes we should
We're currently bumping micro when we do small, backwards compatible
changes like adding an AVOption to an existing module or changing a
default to inform API users of said change. This could be to fix bugs,
or just because the new default is more desirable.
Bug fixes that affect internal bits the user never interacts with
IMO don't justify bumping micro.
Besides, minor is bumped pretty often anyway, making micro almost
superfluous. For example, libavcodec got its latest major bump a year
ago and it's already at minor 51. That's like a minor bump per week.
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel