Mario, In my opinion we, as a community, should avoid trying to to be on the cutting edge of any external dependencies/runtimes. Being on cutting edge forces constant alignment burning a lot of dev cycles to just keep up. The same cycles could be better invested in the project's features and stability.
By adopting LTS versions of external dependencies, we have more previsibility, stability and security (less CVEs!!). Based on the above, I really would prefer that we always take the LTS approach in regarding any external dependencies. Of course, there’s going to be cases where to implement something we may need a cutting edge feature of an external dependency, but I’d say this should be the exception not the norm… and would be better discussed case by case. I'd like to suggest that, to avoid a contentious topic for now, we stick with LTS and once we have a release out we start discussing LTS and cutting edge in possible different streams. On Wed, Nov 22, 2023 at 7:04 AM Pere Fernandez <[email protected]> wrote: > > Thank you Mario for triggering this! > > I will try to get some time this week to take a look into kogito-apps, I'm > pretty sure those patches will require a lot of changes... > > On Wed, 22 Nov 2023 at 12:01, Tibor Zimányi <[email protected]> wrote: > > > Hi Mario,thank you for the effort. I will try to find time to help with > > this by the end of this week. As far as LTS, I think the ideal scenario is > > to have two streams, similarly as Quarkus, or JDK. One stable and second > > one LTS. That topic is for a separate thread though. Best regards, Tibor > > -------- Pôvodná správa --------Od: Mario Fusco <[email protected]> > > Dátum: 22. 11. 2023 11:30 (GMT+01:00) Komu: [email protected] Predmet: > > [URGENT] Finalizing Quarkus 3 migration Hi all,Sorry if I try to rush this, > > but weeks and months are passing and we really really need to finalize the > > migration to Quarkus 3 asap.Yesterday I created a branch of Drools that > > bumps it to the latest Quarkus (3.5.2), see > > https://github.com/apache/incubator-kie-drools/compare/quarkus3We're also > > discuss this on zulip ( please join the conversation here > > https://kie.zulipchat.com/#narrow/stream/381961-drools-dev/topic/Quarkus.203.20migration > > ) and Alex noted that it would be probably better to migrate to the Quarkus > > LTS instead. Personally I'm not strongly opinionated about this, even > > though I don't see any relevant reason for us to stay on the LTS. I'd > > rather prefer to stay on the latest stable quarkus release, especially for > > the community version, and if necessary having a branch for product that is > > on the LTS instead. Anyway please also provide your feedback about this and > > let's take a definitive decision on it.As you can read in that zulip > > thread, Toshiya is now trying to do the same migration for kogito-runtimes, > > but neither him nor me are completely knowledgeable on some parts of that > > project, so please try to be proactive and help him if necessary.Regarding > > the migration of the Drools project, that was not straightforward as I > > hoped also because the existing script was made to run against an alpha > > version of Quarkus 3.0 and however its nightly build didn't run for the > > latest 2 months or a little more. For this reason, and also because I don't > > want to go through this painfully long migration process again, from now on > > I will consider that quarkus3 branch the drools "effective main" branch. I > > don't expect any change in the drools code base in the next days, but if we > > will have any I will forward port any changes to that branch.For the > > remaining part of this email I will list the issues that I found in the > > Drools migration and how I fixed them, hoping that this will be useful also > > for the migrations of other downstream projects:1. The internal Quarkus > > migration recipes have been moved to a different package, see > > https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-23f379d4198b67e1c8c6f0f41711b5bc41264a47aeac55858959c220d60798cfL15-R172. > > Also the URL of the yaml file used by the Quarkus migration script is > > different, see > > https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-23f379d4198b67e1c8c6f0f41711b5bc41264a47aeac55858959c220d60798cfL48-R483. > > The Quarkus migration also implies a bump of the JavaParser version in use. > > The only relevant difference that I found in our code related to this is > > that the ClassDeclaration constructor is changed to accommodate the sealed > > classes introduced in Java 17, see > > https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-7d5b9cbee13948b86436fc081410cb6d1a75870617072a40d66c5a6546f612f6L1416-R14184. > > The Quarkus classloading mechanism is a little different now. The most > > relevant change is that the deployment and augmentation phases are clearly > > separated and use 2 independent classloaders. Due to this change I had to > > introduce this fix > > https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-e6b9a9449de05f2b1a3a76adc52b3691319f9243350d1776f9d262fcf10a881aR50-R58 > > that basically performs a lookup of a type of a variable of a rule unit in > > the same classloader where the DataSource class has been loaded. Without > > this fix the method checking if that type is actually a DataSource ( > > https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-e6b9a9449de05f2b1a3a76adc52b3691319f9243350d1776f9d262fcf10a881aR67 > > ) wouldn't work anymore thus preventing the rule unit to be correctly > > complied. I honestly don't know if this fix could have some implication > > downstream in kogito or more likely if it will have to be propagated > > somewhere also there.5. The same Quarkus classloading changes also required > > a fix in the kie services lookup mechanism, see > > https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-030652eeecd63a0d44385d02b3c362fdda79600785d5e817380daf62e29d3cffL50-R50 > > Actually there I implemented a hack to make Quarkus 2 to work (it was > > necessary to perform the service implementations lookup in the same > > classloader of the service interface) and I'm happy that this is no longer > > needed.My goal is to have also kogito-runtime migrated to Quarkus 3 before > > the end of this week and make those quarkus3 branches our main branches at > > the beginning of the next. I understand that this would eventually break > > other downstream projects, but I believe that it will be easier to fix them > > and anyway I don't see any alternative to push this forward. Please let me > > know if you have any feedback or question on > > this.Thanks,Mario---------------------------------------------------------------------To > > unsubscribe, e-mail: [email protected] additional > > commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
