[FFmpeg-devel] [Discussion] Releases schedules

[ffmpegandmahanstreamer at e.email]

September 12, 2021 1:15 PM, "Jean-Baptiste Kempf" <jb at videolan.org> wrote:

> Hello folks,
> 
> This is a topic that has come regularly on the table, in various discussions in the community, in
> IRL, on IRC and on the mailing list; but also when talking with downstreams applications and
> distributions...
> 

> Currently, it's quite difficult to know when is coming the next release, which branch is going to
> be maintained for how long, so it's a bit of guess/luck to know which version to use, and many
> people use a random sha1. Even for distributions that have LTS this is difficult. It's also
> annoying for downstreams, that might have some patches above the top of line, or backporting some
> patches. And a few other drawbacks, including security...
> 
> And finally, the maintenance of a branch belongs mostly to the goodwill of a few of us, and it
> could be tiring for them...
> 
> (And for exemple, which branch today has all the security fixes, besides 4.4.x?, without looking at
> the git repo)
> 
> Clarity would help a lot the FFmpeg direct and indirect users.
> So I'd love to start a discussion here, about this topic.
> 
> --- 
> Here is my opinion, depending on what I heard from the downstreams requirements.
> 
> It would be nice to have:
> - one major release per year, allowing to break library API/ABI/behavior, (probably in December to
> fit Ubuntu release schedule),

Yes, definetly. This is in line with gstreamer release schedule, i think they have like 2 major releases a year. 

> - one or two or three small releases per year, adding features, without deprecation nor ABI
> changes, during the year,
Actually, i think the dev/release repo thingy as of right now is great. Maybe just one smalller release at the beginning of the year.

> - mark the major release as LTS every two year, and maintained it for security for a longer time (2
> years, for example) than the usual main release.

Also a great idea. 

> 
> This would allow to only have to maintain the LTS branch and the last release (which can be the
> same) in addition with the development branch.
> And as a downstream dev, you also know when you need to care about API changes and which version is
> supported.
> This would be also quite simple to explain to the users/downstreams of FFmpeg.
> 
Yes, good idea.
> Thoughts?

Excellent thoughts like this makes me glad you are involved with the FFmpeg community. Thanks for single handedly putting forth this amazing proposal. FFmpeg will be better for it once there are enacted.
> 
> -- 
> Jean-Baptiste Kempf - President
> +33 672 704 734
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".