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
