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 <airsaylong...@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, sif...@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 <chee...@monkeysintown.com> > *Sent:* Wednesday, 30 September 2020 5:25 PM > *To:* Dev <dev@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 <m...@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, <awa...@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 <edca...@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 <bgo...@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 < > chee...@monkeysintown.com> wrote: > > +1 ... like it. > > > > On Wed, Sep 30, 2020 at 1:09 PM Michael Vorburger <m...@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, < > chee...@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 > > edca...@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> > > > >
