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

Michael Niedermayer michael at niedermayer.cc
Wed Aug 19 21:37:36 CEST 2015


On Wed, Aug 19, 2015 at 08:55:53PM +0200, Andreas Cadhalpun wrote:
> 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.

ok, applied


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

no, of course not

thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150819/ce125d33/attachment.sig>


More information about the ffmpeg-devel mailing list