On 3/25/2026 7:11 PM, Marton Balint via ffmpeg-devel wrote:
On Thu, 19 Mar 2026, Gyan Doshi via ffmpeg-devel wrote:On 2026-03-19 06:02 am, Michael Niedermayer via ffmpeg-devel wrote:we have written "3 months" for the milestones about fixing security/ fuzzerissues corresponding to the releases: https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2025 and that resulted in March, June and September in the contract. If people want that changed, we can talk with STF about that. But if we do that it should happen now not in june3 months seems too short to warrant a new branch. At least it should be 4 months for a regular cadence.We actually used a 6 month schedule in the past few years for releases. The more release branches we have, the more work backporting the security fixes will be, so I am not really convinced it is a good idea to have releases too often, 6 month seemed like a good compromise. Especially if you intend to make an effort to maintain some release branches (are we still considering x.1 branches LTS?) for an extended period.
8.1 is not meant to be LTS. So far, official LTS releases are 5.1 and 7.1, each two years apart. But in practice, releases that end up in big distros (as listed in downstreams from the Trac wiki) end up being LTS simply because Michael will keep backporting stuff to them. 4.4 is still getting updates i assume because of Ubuntu 22.04, and 6.1 I'm sure will continue for a few years because of Ubuntu 24.04, despite neither of them being LTS (fortunately, for 26.04 they seem to have stuck with 7.1 instead of having migrated to 8.0).
Ideally, we'd get strict with tagging our releases as LTS and have distros understand the consequences of shipping an EOL'd release, but i don't know if there's any motivation for that.
As for STF milestones, maybe some more general wording could be used, such as "fix all reproducible security issues reported until 2026-xx-xx in git master and the last release branch of ffmpeg".
I'd love clear, enforced rules, yes. Something like one LTS every two years (and never a x.0, which are always the first after a major bump). One release every six months, and a guarantee of security and bug fix backports for non-LTS releases for at least a year or so (After that, up to people wanting to bother backporting and tagging a point release). Then again, i have the feeling we did come up with some, but then it was more or less ignored.
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
