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