Thanks for starting the discussion, Istvan! IMO, while we can define branch EOL strategy, it still depends a lot on our community's bandwidth to create and publish releases. Therefore, we can make it case-by-case basis.
For instance, it might sound better to leave the backport to committer's discretion for non active release lines (e.g. 5.1), we should definitely target CVE and other critical fixes by creating backport PRs, until we officially announce EOL for such release branches (5.1). To EOL a release line, while not mandatory, it would be advisable to publish at least one last release before officially EOL'ing the release line. This is applicable to both 5.1 and 5.2 release lines. This again depends on our bandwidth to publish releases. I believe we should only discourage commits to officially EOL'ed branches (e.g. 4.16, 4.x as of today). On Mon, Dec 2, 2024 at 12:15 PM Istvan Toth <st...@apache.org> wrote: > Hi! > > AFAIK we don't really have a policy (perhaps by accident, perhaps by > design) on the handling of older branches, EOL, etc. > > De facto, we have traditionally de facto EOLed the previous branch at or > around the release of the next minor version. > > Question 1: > > Do we want to officially EOL releases ? If yes, then then do we want a > written policy for that, or decide on a case-by case basis ? > > Question 2 (depending on Question 1): > > How should we handle non-current release branches (currently 5.1) ? > > - Should we maintain (and require non-problematic fixes to be backported > to) them until they are officially EOLed ? > - Should we keep them open (even after EOL, if we do explicit EOL), and > leave it to the committer's discretion whether to backport or not ? > - Should we close them and discourage commits ? > > > Personally, for $dayjob it is convenient for us to backport some of our > fixes to older (really 1 release behind) branches, as we have a long > support tail. It may also be useful for users who cannot or choose not to > upgrade for some reason or another. At the same time, requiring this from > every committer would be a waste of effort. > > Looking forward to learning your opinion. > > Istvan >
