+1 El lun, 16 oct 2023, 12:53, Pere Fernandez <[email protected]> escribió:
> 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 > > > > > >
