[FFmpeg-devel] [PATCH] */version.h: Add note/recommandition about bumping major

[Andreas Cadhalpun]

On 19.08.2015 11:56, Michael Niedermayer wrote:
> On Tue, Aug 18, 2015 at 11:52:39PM +0200, Andreas Cadhalpun wrote:
>> On 18.08.2015 12:28, Michael Niedermayer wrote:
>>> From: Michael Niedermayer <michael at niedermayer.cc>
>>>
>>> If preferred, i can also apply this after the bump, in case its felt that
>>> this would cause too much delay/work
>>>
>>> Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
>>> ---
>>>  libavcodec/version.h  |    4 ++++
>>>  libavformat/version.h |    5 +++++
>>>  libavutil/version.h   |    4 ++++
>>>  3 files changed, 13 insertions(+)
>>>
>>> diff --git a/libavcodec/version.h b/libavcodec/version.h
>>> index 1b37a9e..cf9c924 100644
>>> --- a/libavcodec/version.h
>>> +++ b/libavcodec/version.h
>>> @@ -46,6 +46,10 @@
>>>   * FF_API_* defines may be placed below to indicate public API that will be
>>>   * dropped at a future version bump. The defines themselves are not part of
>>>   * the public API and may change, break or disappear at any time.
>>> + *
>>> + * @note, when bumping the major version it is recommandeded to manually
>>> + * disable each FF_API_* in its own commit instead of disabling them all
>>> + * at once through the bump. This improves the git bissect-ability of the change.
>>>   */
>>
>> I think that is a good idea,
> 
> 
>> but instead of disabling the FF_API_* defines
>> they should be removed together with the code guarded by them.
>> Otherwise chances are that the old, disabled code will never get removed,
>> see e.g. FF_API_OLD_GRAPH_PARSE.
> 
> that would increase the workload for bumping and also make it harder
> to test for regressions caused by FF_API* in the days/week following
> the bump. so my feeling is toward that keeping disabling and removing
> seperate would be better

You have a point there, so I'm fine with that approach too.

Though, of course, there shouldn't be any regressions in the first place. ;)

Best regards,
Andreas