From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id E55A84538B for ; Thu, 26 Jan 2023 22:16:26 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id AA11C68BD0F; Fri, 27 Jan 2023 00:16:23 +0200 (EET) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 212DF68BB33 for ; Fri, 27 Jan 2023 00:16:17 +0200 (EET) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id BB2431BF203 for ; Thu, 26 Jan 2023 22:16:15 +0000 (UTC) Date: Thu, 26 Jan 2023 23:16:14 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230126221614.GD1949656@pb2> References: <20230116133840.512-1-jamrial@gmail.com> <167457514256.4503.7425182589774123747@lain.khirnov.net> <6b01240d-95e2-db84-c40b-329a72b958c5@gmail.com> <7debdfb5-bbb3-e4c6-f95-a89a463d3abd@passwd.hu> <4997c7ce-3db3-4062-b3b4-f65719debc43@betaapp.fastmail.com> <4ee57c81-5811-4590-84f9-518104d1ce48@betaapp.fastmail.com> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH 00/26] Major library version bump X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============6884260079938188226==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============6884260079938188226== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="v0AS7uCPPFvPHUfF" Content-Disposition: inline --v0AS7uCPPFvPHUfF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 26, 2023 at 12:25:39AM +0100, Marton Balint wrote: >=20 >=20 > On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: >=20 > > On Wed, 25 Jan 2023, at 23:28, Marton Balint wrote: > > > On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: > > >=20 > > > > On Wed, 25 Jan 2023, at 22:03, Marton Balint wrote: > > > > > On Wed, 25 Jan 2023, Jean-Baptiste Kempf wrote: > > > > >=20 > > > > > > On Wed, 25 Jan 2023, at 21:08, Marton Balint wrote: > > > > > > > On Wed, 25 Jan 2023, James Almer wrote: > > > > > > >=20 > > > > > > > > On 1/24/2023 12:45 PM, Anton Khirnov wrote: > > > > > > > > > So to summarize the discussion so far: > > > > > > > > >=20 > > > > > > > > > * nobody is strongly arguing for an instability period a= fter the bump, > > > > > > > > > and there are good reasons against it, therefore we s= hould NOT have > > > > > > > > > one > > > > > > > > >=20 > > > > > > > > > * the bump can be done either as bump-then-remove or rem= ove-then-bump > > > > > > > > > * there are advantages and disadvantages for both o= f those, nobody > > > > > > > > > expressed a strong preference for either, so you = can keep this as > > > > > > > > > is > > > > > > > > >=20 > > > > > > > > > Please correct me if I misunderstood or missed something= , or somebody > > > > > > > > > has a new opinion. > > > > > > > >=20 > > > > > > > > Since the instability period doesn't seem popular, if anyon= e has some patches > > > > > > > > for ABI changes (enum value or field offset changes, removi= ng avpriv_ > > > > > > > > functions we forgot about, etc), then please send them asap= so i can push > > > > > > > > them all at the same time. > > > > > > >=20 > > > > > > > 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 bra= nched first. > > > > > >=20 > > > > > > Why? 5.1 was already branched out. > > > > >=20 > > > > > And is missing 6 months of development. > > > >=20 > > > > So you want us to release both 6.0 and 5.2 at the same time? > > > > I don't get it. > > >=20 > > > 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 additio= n. > >=20 > > Because that's what we agreed on? > > Do a major release every year in Dec/Jan with an ABI/API breakage at th= at time. > >=20 > > 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 tr= ust. >=20 > 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 befo= re to give time for stabilization and to give max features to the old API/A= BI 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 st= ability 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 somet= hing major that needs fixing. I think someone should document these time windows for major distros somewh= ere 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 r= elease versions are available from the website for download, FFmpeg develop= ers 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 ?=20 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 [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange --v0AS7uCPPFvPHUfF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCY9L7pgAKCRBhHseHBAsP q5UFAJ99U8wJtFIP+8iHebD+9Uj/1H4nMwCdHdbJ0fU/dbIA4rMCtItpFoufeKo= =E9oN -----END PGP SIGNATURE----- --v0AS7uCPPFvPHUfF-- --===============6884260079938188226== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============6884260079938188226==--