Thank you Viraj! I mostly agree with your suggestions.
My only problem is with the suggested final release. If we do not EOL releases in a relatively timely manner, then releasing a final version at some point in the future would not be useful, and potentially confusing. For example, if we officially EOL 5.0 in a few years, then I don't see much value in releasing a new 5.0.x version at that time. Everyone has moved on in the several years, and any existing clusters are probably forgotten and not updated anymore. On the other hand, 5.1 is actively used by many (probably most) users, so doing additional 5.1.x releases in the next 1-2 years would obviously add value. Doing a new 5.1.x release five years from now would be much more dubiously useful. On Mon, Dec 2, 2024 at 2:42 PM Viraj Jasani <vjas...@apache.org> wrote: > 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 > > > -- *István Tóth* | Sr. Staff Software Engineer *Email*: st...@cloudera.com cloudera.com <https://www.cloudera.com> [image: Cloudera] <https://www.cloudera.com/> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera> ------------------------------ ------------------------------
