Quoting Derek Buitenhuis (2016-02-26 16:02:18) > Some context: > https://mailman.videolan.org/pipermail/vlc-devel/2016-February/106310.html > > Basically, I would like to propose the following: > > In the future, for major version bumps, we should push the commit > which bumps the version before the big list of commits that remove > all the deprecated code, rather than after. The reasons are as follows: > > 1. All the deprecated code is already hidden under deprecation guards > which check the version. This would properly be disabled with a version > bump, ensuring that at no point in the git history, does this new major > version contain usable versions of the deprecated to-be-remove APIs. > 2. It ensures that at no point in the git history has a feature removed > without a way check for it via version, as has occurred previously, > if you were to pull or checkout a commit in between code removal > and version bump. > > Comments and arguments/reasoning for the current procedure are welcome.
Hmm, I guess I wasn't paying enough attention during the last bump. I fully agree that first doing the bump and only then removing the (now disabled) code is the only way that makes sense and the way it should always be done. It was also the way I did the two previous bumps. This could be put into writing somewhere, but not sure where. The wiki perhaps? Or developer.texi. Not sure anyone doing the bumps actually reads those. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
