From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ffmpeg-devel-bounces@ffmpeg.org> Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 7A37E43792 for <ffmpegdev@gitmailbox.com>; Thu, 26 Jan 2023 23:20:03 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9308668BD81; Fri, 27 Jan 2023 01:20:00 +0200 (EET) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 2A7F768B0F9 for <ffmpeg-devel@ffmpeg.org>; Fri, 27 Jan 2023 01:19:54 +0200 (EET) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id 35C46FF808 for <ffmpeg-devel@ffmpeg.org>; Thu, 26 Jan 2023 23:19:52 +0000 (UTC) Date: Fri, 27 Jan 2023 00:19:52 +0100 From: Michael Niedermayer <michael@niedermayer.cc> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Message-ID: <20230126231952.GE1949656@pb2> References: <6b01240d-95e2-db84-c40b-329a72b958c5@gmail.com> <7debdfb5-bbb3-e4c6-f95-a89a463d3abd@passwd.hu> <accb0c42-0638-4f84-acce-0bd2f3ed1b8d@betaapp.fastmail.com> <a2558c28-cb1a-ff6c-4753-5aaaadca28e1@passwd.hu> <4997c7ce-3db3-4062-b3b4-f65719debc43@betaapp.fastmail.com> <b49f585b-467d-dd94-2a44-278a17609792@passwd.hu> <4ee57c81-5811-4590-84f9-518104d1ce48@betaapp.fastmail.com> <b9a0119-23d0-a649-d71f-ab9e5990f72f@passwd.hu> <20230126221614.GD1949656@pb2> <a6409b62-8858-4d13-a667-74e784de1248@betaapp.fastmail.com> MIME-Version: 1.0 In-Reply-To: <a6409b62-8858-4d13-a667-74e784de1248@betaapp.fastmail.com> 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 <ffmpeg-devel.ffmpeg.org> List-Unsubscribe: <https://ffmpeg.org/mailman/options/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe> List-Archive: <https://ffmpeg.org/pipermail/ffmpeg-devel> List-Post: <mailto:ffmpeg-devel@ffmpeg.org> List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help> List-Subscribe: <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe> Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Content-Type: multipart/mixed; boundary="===============1408614075272105395==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org> Archived-At: <https://master.gitmailbox.com/ffmpegdev/20230126231952.GE1949656@pb2/> List-Archive: <https://master.gitmailbox.com/ffmpegdev/> List-Post: <mailto:ffmpegdev@gitmailbox.com> --===============1408614075272105395== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nbhHrEdisCJIsSEl" Content-Disposition: inline --nbhHrEdisCJIsSEl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 ti= ming > > against: > > > > 1. We seem to want 2 releases per year >=20 > Yes. >=20 > > 2. If we do a major bump, it should ideally happen after a release not= =20 > > before to give time for stabilization and to give max features to the o= ld=20 > > API/ABI >=20 > We said that one of those release would break ABI and API, and that would= be the > one at the dec/jan time >=20 > > 3. The releases which get into distros should be LTS >=20 > Yes >=20 > > 4. LTS releases should be timed so that they are getting into major=20 > > distros > > 5. What gets into major distros should have maximum features and=20 > > maximum stability > > 6. We should try to stick to what we said previously > > 7. We should have a predictable release cycle >=20 >=20 > > 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 w= hen ? > > also which should be LTS ? >=20 > We've had this discussion the last time, notably for whether we should ma= ke 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 >=20 > We said 5.0, 6.0 and 7.0 would be allowed to break API/ABI, aka big-bumps. >=20 > We said we could do more 5.x or 6.x releases, if we needed more than 2 re= leases per year. >=20 > We discussed that at several developer meetings, including the last one w= e had, a few weeks ago. >=20 > > Btw, did we say that we will bump API/ABI in 6.0 or just that we will m= ake > > 6.0 in dec/jan ?=20 >=20 > Both. >=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 inclu= sion > > in distros >=20 > 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). >=20 > Tbh, I don't see why we should do a 5.2, seeing that 6.0 would be the sam= e features-set with just the ABI change, aka removing deprecated symbols. >=20 > Also, doing a 5.2 which would not be a LTS, while 5.1 is a LTS is not onl= y very weird, but it also goes against what we said last time, that the las= t of the 5.x would be LTS (similar for 7.1). >=20 > 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 r= elease at the same time.=20 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 [...] --=20 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. --nbhHrEdisCJIsSEl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCY9MKkQAKCRBhHseHBAsP q2J3AJ9o1A0QVYTd+WBXnCry8EqFxHq5WgCeKMUrff0oa5CRp9vU3a4tbXUaPJA= =OeOs -----END PGP SIGNATURE----- --nbhHrEdisCJIsSEl-- --===============1408614075272105395== 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". --===============1408614075272105395==--