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