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