Hello team. When we introduced the new release/branching strategy last March, it was clear that we might have to create branches once incompatible changes happen.
Now is the time. (Well, soon). <https://issues.apache.org/jira/browse/OAK-7358> will make incompatible changes (so that we can compile & run on Java 14). I therefore propose to create a branch, from which we can continue to cut releases that are fully compatible with 1.22.0. The good news is that we have confirmed that 1.22.* can be used as drop-in replacement for 1.10.*, thus at the same time (or close to it) we could retire 1.10. The only issue we found was due to slightly changed system behaviour when lazy loading of Lucene index files is in effect. I would therefore propose to disable that feature in the first release from that branch (see <https://issues.apache.org/jira/browse/OAK-7947>, there's a system property for this, we would just have to flip the default value). (And yes, this proposal is equivalent to just replay *any* change made in trunk to 1.10.*) The concrete steps would be: - create the branch based on the tag 1.22.0 - flip the default for lazy loading of Lucene index files - backport selected changes from trunk (such as related to yesterday's CVE) - release 1.22.1 - (later on) retire 1.10.* As to why not to branch based on 1.24.0: I'd like to avoid any confusion about what is "newer". If we released 1.24.1 people might think this is something to upgrade from 1.24.0 from (and that would be incorrect due to the change related to OAK-7947). Feedback appreciated, Julian
