diff mbox

[FFmpeg-devel,1/2] avutil/version: Mention similarities and differences to semver

Message ID 20160806105254.1324-1-michael@niedermayer.cc
State Accepted
Headers show

Commit Message

Michael Niedermayer Aug. 6, 2016, 10:52 a.m. UTC
QUESTION: is this the best place for this ?

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavutil/version.h | 6 ++++++
 1 file changed, 6 insertions(+)

Comments

Carl Eugen Hoyos Aug. 8, 2016, 4:32 p.m. UTC | #1
2016-08-06 12:52 GMT+02:00 Michael Niedermayer <michael@niedermayer.cc>:
> QUESTION: is this the best place for this ?
>
> Signed-off-by: Michael Niedermayer <michael@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?

Carl Eugen
Michael Niedermayer Aug. 8, 2016, 8:09 p.m. UTC | #2
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@niedermayer.cc>:
> > QUESTION: is this the best place for this ?
> >
> > Signed-off-by: Michael Niedermayer <michael@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

[...]
Hendrik Leppkes Aug. 8, 2016, 8:21 p.m. UTC | #3
On Mon, Aug 8, 2016 at 10:09 PM, Michael Niedermayer
<michael@niedermayer.cc> 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@niedermayer.cc>:
>> > QUESTION: is this the best place for this ?
>> >
>> > Signed-off-by: Michael Niedermayer <michael@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
>

Incrementing micro with every single commit sounds silly (which this
comes out to be, every bugfix or change?).
You might as well just generate that from the git commit counter then
and save everyone the pain of increasing that, not to mention constant
conflicts when porting commits between branches.

- Hendrik
Carl Eugen Hoyos Aug. 8, 2016, 8:29 p.m. UTC | #4
Hi!

2016-08-08 22:21 GMT+02:00 Hendrik Leppkes <h.leppkes@gmail.com>:
> Incrementing micro with every single commit sounds silly

Yes

> (which this comes out to be, every bugfix or change?).

No.

Carl Eugen
James Almer Aug. 8, 2016, 9:11 p.m. UTC | #5
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@niedermayer.cc>:
>>> QUESTION: is this the best place for this ?
>>>
>>> Signed-off-by: Michael Niedermayer <michael@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
>
Michael Niedermayer Aug. 29, 2016, 8:30 p.m. UTC | #6
On Sat, Aug 06, 2016 at 12:52:53PM +0200, Michael Niedermayer wrote:
> QUESTION: is this the best place for this ?
> 
> Signed-off-by: Michael Niedermayer <michael@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.
>   *
> + * 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.

i added "in git master", iam not sure this is the best so feel free
to improve

applied


[...]
diff mbox

Patch

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.
  *
+ * 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.
+ *
  * @{
  */