+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 >>>>> >>>>>
