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 >
