+1 El mar., 14 de enero de 2025 4:38 a. m., Arnold Galovics <arn...@apache.org> escribió:
> +1 (binding) > > On Tue, Jan 14, 2025 at 11:12 AM Petri Tuomola <pe...@tuomola.org> wrote: > >> +1 binding >> >> On Tue, 14 Jan 2025, 02:44 Bharath Gowda, <bgo...@mifos.org> wrote: >> >>> +1 (binding) >>> >>> Regards, >>> Bharath >>> Lead Implementation Analyst | Mifos Initiative >>> Skype: live:cbharath4| Mobile: +91.7019635592 >>> http://mifos.org <http://facebook.com/mifos> >>> <http://www.twitter.com/mifos> >>> >>> >>> On Tue, Jan 14, 2025 at 6:10 AM Aleksandar Vidakovic < >>> chee...@monkeysintown.com> wrote: >>> >>>> +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 >>>>>> >>>>>>
