Re: Let's prepare for 1.5.0...

[Airsay Longcon <ai...@gmail.com>]

Also +1 for a 3 months cycle. And dragging back the conversation to what we would.like to see in 1.5.0. And I'm going to be selfish here
1) We should be able to archive saving products like we have for loan products. When a product is no longer offered by the FI, we should be able to mark that product as archived so that no new accounts can be created for that product.
2) Simple Interest. While not widely used across FI, there are some clients that don't compound interest (I have at least two clients with negotiations on going with one). I've seen in the code-base that there were plans for simple interest. I would like to see this in future releases.
3) "Anniversary" Interest posting period. So again some clients don't necessarily post interest on the last day of the week, or month or quarter. What they do is post interest on the "anniversary" date. So for a savings account opened on the 1st of the month, interest is posted on the first of the month for monthly interests. Those opened say on the 29th are posted on the 29th (or the last day of the month if that month doesn't have 29 days like February). A similar thing is done for quarterly or bi-annual postings. 

If there's any confusion I can clarify 

> On 30 Sep 2020, at 17:25, sifiso@skyburgsystems.org wrote:
> 
> 
> +1 for a 3 month cycle. A lot more realistic considering the time it took to release 1.4.0
>  
>  
> From: Aleksandar Vidakovic <ch...@monkeysintown.com> 
> Sent: Wednesday, 30 September 2020 5:25 PM
> To: Dev <de...@fineract.apache.org>
> Subject: Re: Let's prepare for 1.5.0...
>  
> I like the 3 month cycle... for this "first" cycle maybe we can aim beginning of January or end of December? Because then we could have "nice" predictable release dates in January, March, June, September...
>  
> Also agree with Michael's no code freezes... backporting worked nicely in 1.4.0
>  
> On Wed, Sep 30, 2020 at 4:53 PM Michael Vorburger <mi...@vorburger.ch> wrote:
> Targeting a 3 months cycle sounds good to me, and longer term perhaps more realistic than 2 months? So I would suggest 3, for now; possible reduction to a 2 months window later, if our contributions suddenly explode... ;-)
>  
> More specifically, when exactly do you want to start counting? The date of the last release email, 2 weeks ago? Or today-ish, that plus 3 months would mean a 1.5.0 end of December, early January?
>  
> PS: I recommend that we we DO NOT have "code freezes", at all. That's such a 90s concept... ;-) Instead, the RM will just create a (1.5.0) "release branch" - exactly like we did for 1.4.0. That worked great. In parallel, we should continue reviewing and merging into our "develop" branch. Always. The show must go on. Releases should never "stop the world".
>  
> 
> On Wed, 30 Sep 2020, 15:36 Awasum Yannick, <aw...@apache.org> wrote:
> Michael, that is a good idea.
>  
> Ed maybe we could do a release once every 2 or 3 months. A monthly release wont have alot of features based on the contribution rate. But doing it once every 2 or 3 months will have a sizeable list of bug fixes.
>  
> What do you all think?
>  
> On Wed, Sep 30, 2020, 14:06 Ed Cable <ed...@mifos.org> wrote:
> Hi Michael,
>  
> I think it would be good to aim for a time-boxed release cadence. That is what we were aiming for before but I think given we had no release manager and no steady review of PRs, the aim of bi-monthly releases was too ambitious.
>  
> What would you propose as a frequency of release cycle? - Quarterly? 
>  
> The processes and timelines previously proposed and implemented centered around a 2 month period so I think a quarter would give more time to effectively allow the community to prepare their contributions before code freeze dates, etc.
>  
> Ed
>  
>  
>  
> On Wed, Sep 30, 2020 at 5:13 AM Bharath Gowda <bg...@mifos.org> wrote:
> +1 
> It's a great thought, codebase would become more stable with timely fixes and release. also, organizations can plan their work according to the release date.
>  
> 
> Regards,
> Bharath
> Lead Implementation Analyst | Mifos Initiative
> Skype: live:cbharath4| Mobile: +91.7019636073
> http://mifos.org  
>  
>  
> On Wed, Sep 30, 2020 at 5:29 PM Aleksandar Vidakovic <ch...@monkeysintown.com> wrote:
> +1 ... like it.
>  
> On Wed, Sep 30, 2020 at 1:09 PM Michael Vorburger <mi...@vorburger.ch> wrote:
> Hello,
>  
> I have an idea/proposal, for discussion/input:
>  
> How crazy would it be to suggest a strictly time boxed release cadence for Fineract?
>  
> So we would discuss and agree upon a DATE instead of SCOPE for 1.5.0.
>  
> Best,
> M.
>  
> 
> On Wed, 30 Sep 2020, 08:54 Aleksandar Vidakovic, <ch...@monkeysintown.com> wrote:
> Hi everyone,
>  
> ... just wanted to start the discussion on what we want to include for the next release. Let's see if we can establish a more regular release cycle... looking at the current rate of contributions we should definitely have enough material.
>  
> Please chime in and either label existing or new Jira tickets for version 1.5.0 or just send ideas and requests here on the mailing list.
>  
> Cheers,
>  
> Aleks
> 
>  
> --
> Ed Cable
> President/CEO, Mifos Initiative
> edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
>  
> Collectively Creating a World of 3 Billion Maries | http://mifos.org  
>  

Re: Let's prepare for 1.5.0...

[Aleksandar Vidakovic <ch...@monkeysintown.com>]

Could you create Jira tickets for these and label them for version 1.5.0?
That way this stuff stays on the radar... thanks

On Thu, Oct 1, 2020 at 11:32 AM Airsay Longcon <ai...@gmail.com>
wrote:

> Also +1 for a 3 months cycle. And dragging back the conversation to what
> we would.like to see in 1.5.0. And I'm going to be selfish here
> 1) We should be able to archive saving products like we have for loan
> products. When a product is no longer offered by the FI, we should be able
> to mark that product as archived so that no new accounts can be created for
> that product.
> 2) Simple Interest. While not widely used across FI, there are some
> clients that don't compound interest (I have at least two clients with
> negotiations on going with one). I've seen in the code-base that there were
> plans for simple interest. I would like to see this in future releases.
> 3) "Anniversary" Interest posting period. So again some clients don't
> necessarily post interest on the last day of the week, or month or quarter.
> What they do is post interest on the "anniversary" date. So for a savings
> account opened on the 1st of the month, interest is posted on the first of
> the month for monthly interests. Those opened say on the 29th are posted on
> the 29th (or the last day of the month if that month doesn't have 29 days
> like February). A similar thing is done for quarterly or bi-annual
> postings.
>
> If there's any confusion I can clarify
>
> On 30 Sep 2020, at 17:25, sifiso@skyburgsystems.org wrote:
>
> 
>
> +1 for a 3 month cycle. A lot more realistic considering the time it took
> to release 1.4.0
>
>
>
>
>
> *From:* Aleksandar Vidakovic <ch...@monkeysintown.com>
> *Sent:* Wednesday, 30 September 2020 5:25 PM
> *To:* Dev <de...@fineract.apache.org>
> *Subject:* Re: Let's prepare for 1.5.0...
>
>
>
> I like the 3 month cycle... for this "first" cycle maybe we can aim
> beginning of January or end of December? Because then we could have "nice"
> predictable release dates in January, March, June, September...
>
>
>
> Also agree with Michael's no code freezes... backporting worked nicely in
> 1.4.0
>
>
>
> On Wed, Sep 30, 2020 at 4:53 PM Michael Vorburger <mi...@vorburger.ch>
> wrote:
>
> Targeting a 3 months cycle sounds good to me, and longer term perhaps more
> realistic than 2 months? So I would suggest 3, for now; possible reduction
> to a 2 months window later, if our contributions suddenly explode... ;-)
>
>
>
> More specifically, when exactly do you want to start counting? The date of
> the last release email, 2 weeks ago? Or today-ish, that plus 3 months would
> mean a 1.5.0 end of December, early January?
>
>
>
> PS: I recommend that we we DO NOT have "code freezes", at all. That's such
> a 90s concept... ;-) Instead, the RM will just create a (1.5.0) "release
> branch" - exactly like we did for 1.4.0. That worked great. In parallel, we
> should continue reviewing and merging into our "develop" branch. Always.
> The show must go on. Releases should never "stop the world".
>
>
>
> On Wed, 30 Sep 2020, 15:36 Awasum Yannick, <aw...@apache.org> wrote:
>
> Michael, that is a good idea.
>
>
>
> Ed maybe we could do a release once every 2 or 3 months. A monthly release
> wont have alot of features based on the contribution rate. But doing it
> once every 2 or 3 months will have a sizeable list of bug fixes.
>
>
>
> What do you all think?
>
>
>
> On Wed, Sep 30, 2020, 14:06 Ed Cable <ed...@mifos.org> wrote:
>
> Hi Michael,
>
>
>
> I think it would be good to aim for a time-boxed release cadence. That is
> what we were aiming for before but I think given we had no release manager
> and no steady review of PRs, the aim of bi-monthly releases was too
> ambitious.
>
>
>
> What would you propose as a frequency of release cycle? - Quarterly?
>
>
>
> The processes and timelines previously proposed and implemented centered
> around a 2 month period so I think a quarter would give more time to
> effectively allow the community to prepare their contributions before code
> freeze dates, etc.
>
>
>
> Ed
>
>
>
>
>
>
>
> On Wed, Sep 30, 2020 at 5:13 AM Bharath Gowda <bg...@mifos.org> wrote:
>
> +1
>
> It's a great thought, codebase would become more stable with timely fixes
> and release. also, organizations can plan their work according to the
> release date.
>
>
>
>
> Regards,
>
> Bharath
>
> Lead Implementation Analyst | Mifos Initiative
>
> Skype: live:cbharath4| Mobile: +91.7019636073
>
> http://mifos.org  <http://facebook.com/mifos>
> <http://www.twitter.com/mifos>
>
>
>
>
>
> On Wed, Sep 30, 2020 at 5:29 PM Aleksandar Vidakovic <
> cheetah@monkeysintown.com> wrote:
>
> +1 ... like it.
>
>
>
> On Wed, Sep 30, 2020 at 1:09 PM Michael Vorburger <mi...@vorburger.ch>
> wrote:
>
> Hello,
>
>
>
> I have an idea/proposal, for discussion/input:
>
>
>
> How crazy would it be to suggest a strictly time boxed release cadence for
> Fineract?
>
>
>
> So we would discuss and agree upon a DATE instead of SCOPE for 1.5.0.
>
>
>
> Best,
>
> M.
>
>
>
> On Wed, 30 Sep 2020, 08:54 Aleksandar Vidakovic, <
> cheetah@monkeysintown.com> wrote:
>
> Hi everyone,
>
>
>
> ... just wanted to start the discussion on what we want to include for the
> next release. Let's see if we can establish a more regular release cycle...
> looking at the current rate of contributions we should definitely have
> enough material.
>
>
>
> Please chime in and either label existing or new Jira tickets for version
> 1.5.0 or just send ideas and requests here on the mailing list.
>
>
>
> Cheers,
>
>
>
> Aleks
>
>
>
>
> --
>
> *Ed Cable*
>
> President/CEO, Mifos Initiative
>
> edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
>
>
>
> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
> <http://facebook.com/mifos>  <http://www.twitter.com/mifos>
>
>
>
>