Please indicate: [+1] in favor [-1] opposed [0] neutral and if your vote is binding. (PMC member)
Let's complete voting within 48 hours or I will assume lazy consensus on this. (lack of discussion suggests that to me) ---------- Forwarded message --------- From: James Dailey <jamespdai...@gmail.com> Date: Mon, Jan 13, 2025 at 4:23 PM Subject: Re: [DISCUSS] Remove support for any non-current version To: <dev@fineract.apache.org> Adam - thanks for the input. Seeing no other discussion, I'm calling a vote next. On Thu, Jan 9, 2025 at 1:09 AM Ádám Sághy <adamsa...@gmail.com> wrote: > 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, <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 > >
