[FFmpeg-devel] 5.0 release

[James Almer]

On 1/2/2022 11:12 AM, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2021-12-31 20:40:24)
>> On Fri, Dec 31, 2021 at 10:45:46PM +0530, Gyan Doshi wrote:
>>>
>>>
>>> On 2021-12-31 10:22 pm, Michael Niedermayer wrote:
>>>> On Tue, Dec 28, 2021 at 12:55:14AM +0100, Michael Niedermayer wrote:
>>>>> On Wed, Dec 22, 2021 at 05:44:42PM +0100, Jean-Baptiste Kempf wrote:
>>>>>> On Wed, 22 Dec 2021, at 15:05, James Almer wrote:
>>>>>>> Is the December target to get into the feature freeze schedule from
>>>>>>> distros?
>>>>>> No, it was set by me, in order to get the distro freezes from January.
>>>>>>
>>>>>> We can miss the target a bit this year, and then make it better for 2022.
>>>>> as you seem to know the distro freeze shedules
>>>>> can you clarify "a bit" ?
>>>>>
>>>>> iam asking just in case the channel patch doesnt make it before
>>>>> so i know when its time to stop waiting for it
>>>> ok
>>>> when do people want me to make the branch ?
>>>> any preferrances ?
>>>> should i do it now or continue waiting?
>>>>
>>>> I saw on IRC some sugestions to make it at a past commit to keep some
>>>> code out
>>>
>>> It would be nice to have a public date set a few days into the future.
>>
>> yes, i intended to do that, unless people wanted a ASAP/NOW branch
>>
>> i guess 3rd january seems like a good choice
>> 1st and 2nd as being close to newyear probably would not be ideal so
>> 3rd seems the soonest good date
>> but we can push this out more if people want? or also do it earlier
>> of course that assumes nothing unexpected happens
>> (and something unexpected always happens...)
> 
> 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.

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