I like Alex's approach to sticking to LTS for now and having a larger discussion later.
On 2023/11/22 14:25:25 Alex Porcelli wrote: > 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 <pere.fernan...@gmail.com> > 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 <tibor.zima...@gmail.com> 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 <mariofu...@apache.org> > > > Dátum: 22. 11. 2023 11:30 (GMT+01:00) Komu: dev@kie.apache.org 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: dev-unsubscribe@kie.apache.orgFor additional > > > commands, e-mail: dev-h...@kie.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > For additional commands, e-mail: dev-h...@kie.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org For additional commands, e-mail: dev-h...@kie.apache.org
