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

[Michael Niedermayer]

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

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Whats the most studid thing your enemy could do ? Blow himself up
Whats the most studid thing you could do ? Give up your rights and
freedom because your enemy blew himself up.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20230127/4e0877c5/attachment.sig>