[FFmpeg-devel] 5.0 release

[Zane van Iperen]

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.