On Monday, 3 January 2022 12:29:02 AM AEST James Almer wrote: > > There were some disagreements on IRC a few days ago about what should > > and should not go into the release because of insufficient fuzzing and > > the danger of introducing security issues. > > > > To avoid conflicts around this in the future, I'd suggest (for future > > releases) to create the release branch a significant time (e.g. a month) > > before doing the actual release. > > > > Opinions? > > It's a good idea, but we need to be strict about it. As in, we need to > state that the moment the branch is made it's a definite feature freeze, > and only fixes, documentation changes and similar may be cherry-picked > into it (meaning nothing that usually comes with a version bump, even if > micro), much like we do for a point release, even if the initial release > was not tagged yet. >
I completely agree, this is a *very* good idea. If people treat it like an existing release branch, i.e. only bugfixes, etc., then it would save this from happening again. Also means there wouldn't need to be a "don't add big things" announcement _somewhere_ on the ML. > Reverting something in the release branch is already going to be dirty > no matter what, because we do a minor bump to ensure the release has its > own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking > a demuxer available in lavf 59.12 Depends on what you mean by "lacking a demuxer"... One (hacky) option would be to replace it with a stub implementation that always fails. Or we could just branch off at 7cee3b3718 and cherry-pick anything we need back. There's only like four commits that need it (so far): 2f6360ff21, 9cfc7a2440, c417616762, and d6b2357edd. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
