Dear James and fellow community members, Here comes my 2 cents:
Taking into consideration our releases have been infrequent, I would say supporting only the current release makes sense to me! We can always decide later we would like to backport a security fix optionally…. Regards, Adam > On 8 Jan 2025, at 19:57, James Dailey <jdai...@apache.org> wrote: > > All - Our current support promise is to support at least one version back. > We do not backport the security fixes to any previous releases except for > "one version before". That is the current policy internally, and it is up to > us to decide if we want to continue. > > Our releases have been infrequent and backporting security fixes to previous > releases seems quite out of reach given the amount of capacity we seem to > have for this. > > I also note that we get very few queries when we do so for upgrades. My > intuition is that most folks are either building their internal production > from the tip of dev on github or upgrading via patch for critical items. > > Therefore, my proposal, which we need to VOTE on, is to remove support for > any non-current release. That is, when we do a release, we will need only to > support the current release. Previous releases will immediately become > unsupported. There will be a period of at least one week of notice prior to a > release happening. > > The implication for this is that the CVEs, when they are revealed, will be > available as an attack vector. We do so according to published ASF practices. > So, that is the downside, but I believe it is manageable if production users > are aware and able to find the code fixes according to our practices and > apply as necessary to their instances, or to upgrade. > > My current plan is to remove the release 1.9 from the website and move it to > archives. So, even if we have this policy, for me to complete release > 1.10.1, and move onto release 1.11.0 we will need to do this. (unless > someone steps up) > > The new policy would read: > The fineract project sets the expectation that only the current release has > fixes to public CVEs and no backporting of those CVEs to previous versions > will take place, except in unusual situations. If there are available > resources, the community can expect one previous version support and in the > future there may be a decision to have a "long term support" (LTS) version. > Until then, we commit to making a one week notification of end of life for > all previous versions. > > Moreover, I am now informing the community of an exceptional case to our > current policy, which is that the version 1.9.0 is end of life (EOL) within > the next 7 days. > > If you have views on this specific topic, please share. Discussion open for > 72 hrs. Then I will call for a VOTE. > > Thanks, > - James > PMC member, current release manager > PMC Chair
