another +1. Currently the Quarkus 3 / Springboot 3.5 migration patches are broken again and should be repaired once more. I'm worried that this situation will keep happening every time new commits are merged into main. So I totally agree on tackling this the sooner we can.
On Mon, 16 Oct 2023 at 12:44, Kris Verlaenen <[email protected]> wrote: > +1 on these steps. On timing, I would suggest we try to get our release > pipelines up and running first (doing a 1.45.0) and then follow up with > these steps for an equivalent 2.45.0 on Quarkus3. Mostly so we can wrap up > and validate one step (the release pipelines) before we jump to the next > big step. > > Thx, > Kris > > On Mon, Oct 16, 2023 at 12:18 PM Mario Fusco <[email protected]> > wrote: > > > Hi all, > > > > As mentioned during last Friday's meeting, I believe that we should move > > any forward upstream development to Quarkus 3 and Jakarta namespace. > That's > > because the effort of developing against both Quarkus 2.x and 3.x will be > > hardly bearable and the current setup that automatically migrates our > > upstream branches (based on Quarkus2/JavaEE) to Quarkus 3 through > > openrewrite is demonstrating all its limitations. Openrewrite is an > amazing > > tool, but it is mostly intended for one-shoot migration so in my opinion > > our usage pattern is a sort of abuse, and even worse it doesn't allow us > to > > work effectively on proper Quarkus 3 integration. > > > > Related to this we should also discuss which extensions we want to make > > available with Quarkus 3. Last week I implemented and merged a commit > > moving the last rules related feature that was still available only > through > > Kogito (the automatic rest endpoints generation from rule units queries) > > back into Drools. At this point I think that having a Kogito extension > for > > rules that simply replicates what will be available with the Drools one > > will be unnecessary and only a source of confusion. > > > > To recap my proposal is the following: > > > > 1. From the main branches create branches 1.x for Kogito and 8.x for > > Drools. We will consider these branches in pure maintenance mode and > > backport there only (critical) fixes. > > 2. Apply the openrewrite script one last time to definitively migrate our > > main branches to Quarkus3/Jakarta and eventually fix manually any > > outstanding incompatibility. > > 3. Remove the Kogito rule extension, check if all the remaining > extensions > > still make sense (we should avoid features duplication and overlapping in > > different extensions). > > 4. Implement and publish asap the Quarkus 3 extensions. > > > > As a final note on version numbers, I guess that we don't have many > > alternatives other than tagging the releases made from these new main > > branches by continuing with 2.45.0 for Kogito and 9.45.0 for Drools. This > > could be a bit unusual and confusing for users migrating to these newer > > versions, but the only other possibility that I see would be to jump to > > 3.0.0 and 10.0.0 which will be probably even worse. > > > > Any feedback is welcome. > > > > Thanks, > > Mario > > >
