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 >> >
