This is the plan for the next 4 releases (spanning more or less from spring till winter), it is the result of all the feedback regarding our release process and requests.
Enough people (mostly mpv, vlc and other downstreams tracking us by git commit) would like to have quicker major releases. The API changes introduced are mostly caused by us trying to satisfy their needs after all. A good amount of people (distribution managers/packagers and the people tending to orphaned packages used but not really developed further) have quite a problem keeping up with the changes if the API gets incompatible too often. In order to help them we already opened a dedicated section to our bugzilla[1] and started writing migration guides[2]. Trying to satisfy those two requirements I'd propose to do the following. - Some (every odd should do) major releases should not break the API, happen quickly once enough features are available and just augment API, possibly break ABI. - Major releases removing the API, thus normally source incompatible with downstream not tracking git should happen at most once per season or twice per year. The rule of documenting the API changes in the migration guide when it is committed should mitigate the situation, as long we stick to it. - We do remain committed to backport security-impacting bugfixes through a window of API-breaking releases, thus not leaving in the cold who couldn't or didn't update often enough. I hope ~8 feature improvements and ~4 api cleanups per year would make everybody happy, I'll update the documentation in this regard soon. lu (with Reinhard) _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
