Thanks Aleks . This is great. +1
I like the suggestions and I hope I have sufficient skills to begin contributing soon. Good work 👍 On Mon, Aug 1, 2022, 5:45 PM Aleksandar Vidakovic <[email protected]> wrote: > Hi Victor, > > ... excellent idea Victor... we should really do something like that. > > And you are absolutely right: this would effectively mean that version > will have a End of Life. We don't say that explicitly now and we all know > that some community members are working on versions as far back as 1.3... > when in fact in Fineract upstream the only version we support (as a > community) is the latest. > > Putting a calendar in place will help to better manage expectations of our > users, but will also help us to manage our releases a bit better... to the > point that people start saying "oh, it's March... shouldn't we have a new > Fineract release?"... I'd really like to see that. > > And just to repeat again: any numbers in my initial email are a bit > arbitrary or copied from other projects (e. g. support for 2 minor versions > that's how Spring Boot handles things). We can and should adjust these > numbers once we have more feedback from the community. I hope this can make > life a little bit easier for everyone. > > Cheers, > > Aleks > > On Mon, Aug 1, 2022 at 4:14 PM VICTOR MANUEL ROMERO RODRIGUEZ < > [email protected]> wrote: > >> Thank Aleks, >> >> Quick question, happy to read that a new version is in progress. >> +1 >> >> Do you think it will help to have a calendar for releases? what I mean is >> also related if this will lead to having an End Of Life for previous >> versions (oldest). >> >> Regards >> >> Victor >> >> El lun, 1 ago 2022 a las 5:35, Aleksandar Vidakovic (<[email protected]>) >> escribió: >> >>> Hi everyone, >>> >>> ... it's time again to have another release! This is not the official >>> announcement yet - I'm still waiting for bits of information before I can >>> do that - but wanted to let you know early enough. >>> >>> I will write annother official announcement (when we open the release >>> branch), but here's already a preview of things to come and more insight >>> into the main motivation to create this release (1.8.0) now. >>> >>> Fineract had a very good year 2022 in terms of contributions. If I'm not >>> mistaken a 3rd release within the same year marks a new record for the >>> community. Especially given the type of new features that were already >>> included like database independence, move to Liquibase as our database >>> migration tool, various preparations for increasing Fineract's performance >>> in production deployments and the usual bug fixes and improvements. >>> >>> One motivation to have this release is of course to get the latest >>> improvements, features, bug fixes into your hands as soon as possible >>> (sooner than we did in the past). But there are two more reasons why we do >>> this right now: >>> >>> 1. You might have already seen that we recently (last Thursday) >>> started to add Spring Batch support to Fineract. This will ultimately be >>> a >>> replacement for the old Quartz jobs. We thought it would be a good idea >>> to >>> make a release BEFORE we added such a major improvement and to give the >>> community a release that is more on the conservative side compared to >>> 1.7.0, i. e. make upgrades easier. >>> 2. Another new "feature" will be patch or hotfix releases for >>> Fineract. We all know that in the past we all had to wait quite a bit for >>> the next release to be published (sometimes more than a year). Commercial >>> customers and integrators asked repeatedly if we could have more frequent >>> releases with "less features" to avoid major retesting for production >>> environments. >>> >>> So let me drop a word or two concerning hotfix releases and the need for >>> more stable releases required by commercial users. As we all know - and >>> despite our best efforts to test as much as we can (especially via >>> integration testing) - there's usually additional (manual) testing needed >>> by Fineract users/integrators to make sure everything is running smoothly >>> in production. This can be - and usually is - a lengthy process. >>> >>> With the current state of affairs this means that with every new release >>> we publish, the users have to go through their lengthy manual test process >>> all over again. There are a lot of users that don't want or can't wait >>> a whole year for a new release with bug fixes they need now. This forces >>> them to adopt dangerous strategies like "follow develop branch in >>> production" which is not ideal when major features get integrated upstream. >>> >>> Sometimes (or should we say more often than not) users don't even need >>> nor want the bleeding edge of Fineract and are quite happy with what they >>> have, but instead of new features would like to have fixes for critical >>> bugs and security issues in a timely manner (we mean "days" not "months" or >>> "years"). >>> >>> That's why we've decided to make our release process more flexible (and >>> even more frequent than it currently is) and have hotfix releases. We are >>> still working on the details, but such a release will have a couple of >>> strict policies in place like: >>> >>> - hotfix releases are reserved for critical (BLOCKER) bugs and >>> security issues. Probably we'll have some kind of voting process in >>> place, >>> e. g. "minimum 3 x +1 votes from PMC members"; note: the numbers here are >>> still arbitrary, we'll adapt as we move along and discuss this with you. >>> - we will support (for now to start) two minor versions back >>> counting from the last release; this would mean that once 1.8.0 is out we >>> would support 1.8.x and 1.7.x, but not 1.6.x and older; this rule is >>> tentative, we'll see then what we do in the future when we have more >>> feedback. >>> - guaranteed backward compatibility with the last minor release; i. >>> e. "1.6.1" is a drop-in replacement for "1.6.0" >>> - NO new features, tables, data, REST endpoints >>> - NO major (or "minor" framework upgrades); i. e. if we used Spring >>> Boot "2.6.1" in version "1.6.0" of Fineract we can upgrade dependencies >>> to >>> "2.6.10" (unless it breaks something of course), but not to "2.7.2" of >>> Spring Boot >>> >>> So, in short, to put all these things in place we need to have this >>> release (-branch) to have a proper starting point. >>> >>> There's one more thing I'd like to make you aware of: we have to do a >>> bit of house-cleaning related to our last 1.7.0 release. No worries, it >>> doesn't contain any functional changes, just mostly documentation and minor >>> build script related additions that are not yet merged into the develop >>> branch. I will integrate these changes in our develop branch history via a >>> rebase to make sure they appear in the right place in the timeline. There >>> is only one CAVEAT here for all people that depend on Githashes: all hashes >>> in develop AFTER those 1.7.0 release changes will be updated. This >>> shouldn't be a big problem, because - again - there are no functional >>> changes, just files that usually no one touches are affected (build, doc). >>> If you happen to point to these hashes (aka "follow develop for >>> production") then please be aware of this and adapt your environment >>> accordingly. I'll send out a separate email with more details (last >>> unchanged hash etc.). >>> >>> Will keep you posted... and as usual: please voice your opinions, >>> concerns, tips by commenting on this thread. >>> >>> Cheers, >>> >>> Aleks >>> >>
