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

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 5390 bytes --]

On Thu, Jan 26, 2023 at 12:25:39AM +0100, Marton Balint wrote:
> 
> 
> On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote:
> 
> > On Wed, 25 Jan 2023, at 23:28, Marton Balint wrote:
> > > On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote:
> > > 
> > > > On Wed, 25 Jan 2023, at 22:03, Marton Balint wrote:
> > > > > On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote:
> > > > > 
> > > > > > On Wed, 25 Jan 2023, at 21:08, Marton Balint wrote:
> > > > > > > On Wed, 25 Jan 2023, James Almer wrote:
> > > > > > > 
> > > > > > > > On 1/24/2023 12:45 PM, Anton Khirnov wrote:
> > > > > > > > >  So to summarize the discussion so far:
> > > > > > > > > 
> > > > > > > > >  * nobody is strongly arguing for an instability period after the bump,
> > > > > > > > >     and there are good reasons against it, therefore we should NOT have
> > > > > > > > >     one
> > > > > > > > > 
> > > > > > > > >  * the bump can be done either as bump-then-remove or remove-then-bump
> > > > > > > > >       * there are advantages and disadvantages for both of those, nobody
> > > > > > > > >         expressed a strong preference for either, so you can keep this as
> > > > > > > > >         is
> > > > > > > > > 
> > > > > > > > >  Please correct me if I misunderstood or missed something, or somebody
> > > > > > > > >  has a new opinion.
> > > > > > > > 
> > > > > > > > Since the instability period doesn't seem popular, if anyone has some patches
> > > > > > > > for ABI changes (enum value or field offset changes, removing avpriv_
> > > > > > > > functions we forgot about, etc), then please send them asap so i can push
> > > > > > > > them all at the same time.
> > > > > > > 
> > > > > > > Ok, I can send the frame number changes tomorrow. When do you plan to do
> > > > > > > the actual bump? I assumed the last 5.x release should be branched first.
> > > > > > 
> > > > > > Why? 5.1 was already branched out.
> > > > > 
> > > > > And is missing 6 months of development.
> > > > 
> > > > So you want us to release both 6.0 and 5.2 at the same time?
> > > > I don't get it.
> > > 
> > > I don't see too much benefit in releasing 6.0 right now just because we
> > > bumped API, beacuse API bump typically means API removal, not addition.
> > 
> > Because that's what we agreed on?
> > Do a major release every year in Dec/Jan with an ABI/API breakage at that time.
> > 
> > If you want to do a 5.2, why not, but I don't see the need, especially if 5.1 is the LTS one. But why not...

I can branch release/5.2 and make a release if theres agreement on that ?
I dont think we should tag a release on master that will make point releases
a mess as we need a branch for them

I can also make a release/6.0 and release after the bump but it feels a bit like
there should be a bit time between the bump and the release so teh codebase is
tested a bit after ABI/API changes

> > But not doing what we said about major releases is a big breakage of trust.
> 
> Okay, maybe its just me, but I missed this decision, and I don't remember
> any discussions regarding it. Can you give me some pointers?

I think in general these are the constraints to optimize our release timing
against:

1. We seem to want 2 releases per year
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
3. The releases which get into distros should be LTS
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

Some of these points are easy, some are a bit harder.
to do 4. we (or i) need to know when the window is for distros to pick our release
up, this should ideally leave time for a point release in case theers something major
that needs fixing.
I think someone should document these time windows for major distros somewhere
like on trac so we all know what we are aiming for and why

Now about 6. i asked google about ffmpeg release cycle
it pointed me to a ffmpeg-user post from 2014
https://ffmpeg.org/pipermail/ffmpeg-user/2014-March/020558.html
but that points more to git master than a release cycle

another link goes to wikipedia
"The project publishes a new release every three months on average. While release versions are available from the website for download, FFmpeg developers recommend that users compile the software from source using the latest build from their source code Git version control system"

i have the feeling i will leave that resolution to someone else :)
but iam happy to make releases every 6 or 3 months, later would be more work
of course.

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 ?

Btw, did we say that we will bump API/ABI in 6.0 or just that we will make
6.0 in dec/jan ? 
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

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".