+1 (binding) On Tue, Jan 14, 2025 at 1:26 AM James Dailey <jdai...@apache.org> wrote:
> 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 >> >>
