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 <mich...@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 <mich...@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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
