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 <mich...@niedermayer.cc>:
>>> QUESTION: is this the best place for this ?
>>>
>>> Signed-off-by: Michael Niedermayer <mich...@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@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to