Thanks Aleks - great ideas, and fully supportive of these. Just wondering: do you see that the way we execute this is by keeping the major release branch e.g. 1.7.0 open after doing the release (rather than deleting it), invite people to contribute patches that fulfil the criteria to that branch, and then tag a patch release (and merge same changes also back to develop)? This would in effect make the patch releases potentially larger with a number of patches included in a single patch release.
Or do you see the patch releases more focused on a specific patch only - i.e. we delete the 1.7.0 branch after the release, and create a new branch for 1.7.1 from the 1.7.0 tag only when it’s agreed to have a patch release for a specific issue - then merge the relevant PR into the patch release branch, do the patch release, merge back and delete the patch branch ie 1.7.1. I can see pros/cons in both approaches… what would be your preference? Regards Petri > On 1 Aug 2022, at 6:35 PM, Aleksandar Vidakovic <[email protected]> wrote: > > 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: > 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. > 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
