Re: [FFmpeg-devel] [PATCH 00/26] Major library version bump

["Jean-Baptiste Kempf" <jb@videolan.org>]

On Fri, 27 Jan 2023, at 00:19, Michael Niedermayer wrote:
> On Thu, Jan 26, 2023 at 11:49:14PM +0100, Jean-Baptiste Kempf wrote:
>> On Thu, 26 Jan 2023, at 23:16, Michael Niedermayer wrote:
>> > I think in general these are the constraints to optimize our release timing
>> > against:
>> >
>> > 1. We seem to want 2 releases per year
>> 
>> Yes.
>> 
>> > 2. If we do a major bump, it should ideally happen after a release not 
>> > before to give time for stabilization and to give max features to the old 
>> > API/ABI
>> 
>> We said that one of those release would break ABI and API, and that would be the
>> one at the dec/jan time
>> 
>> > 3. The releases which get into distros should be LTS
>> 
>> Yes
>> 
>> > 4. LTS releases should be timed so that they are getting into major 
>> > distros
>> > 5. What gets into major distros should have maximum features and 
>> > maximum stability
>> > 6. We should try to stick to what we said previously
>> > 7. We should have a predictable release cycle
>> 
>> 
>> > So what do people think ?
>> > when should i branch 5.2, when 6.0 ? and when 6.1 and then 6.2 or 7.0 when ?
>> > also which should be LTS ?
>> 
>> We've had this discussion the last time, notably for whether we should make 5.0 an LTS or 5.1 an LTS and we said:
>> 5.0 in jan 2022, 5.1 in July 2022 with LTS
>> 6.0 in jan 2023, 6.1 in July 2023
>> 7.0 in jan 2024, 7.1 in July 2023 with LTS
>> 
>> We said 5.0, 6.0 and 7.0 would be allowed to break API/ABI, aka big-bumps.
>> 
>> We said we could do more 5.x or 6.x releases, if we needed more than 2 releases per year.
>> 
>> We discussed that at several developer meetings, including the last one we had, a few weeks ago.
>> 
>> > Btw, did we say that we will bump API/ABI in 6.0 or just that we will make
>> > 6.0 in dec/jan ? 
>> 
>> Both.
>> 
>> > Iam pretty bad at remembering these plans, my notes say 6.0 in dec 2022 but
>> > that was not done because it would have competed with the LTS for inclusion
>> > in distros
>> 
>> No, because distro take a LONG time to integrate releases, because of the software dependencies adaptations.
>> So, in Feb, they will use the last release of the previous major branch (here, a 5.1).
>> 
>> Tbh, I don't see why we should do a 5.2, seeing that 6.0 would be the same features-set with just the ABI change, aka removing deprecated symbols.
>> 
>> Also, doing a 5.2 which would not be a LTS, while 5.1 is a LTS is not only very weird, but it also goes against what we said last time, that the last of the 5.x would be LTS (similar for 7.1).
>> 
>> I would just merge the bump, then branch 6.0 branch and wait a few weeks before releasing 6.0.
>> If some people strongly want a 5.2, branch 5.2 before the bump and do a release at the same time. 
>
> ok
> I would suggest one thing, if people want a bump between 2023 6.0 and 2024 7.0
> then the bump should happen closer to 6.1 than 7.0

That is a very fair point, and we should do that next time, to avoid the current mess.
I'm probably partly at fault, here. Sorry.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".