Mario, Kris and team, I’m in favor of moving to Quarkus v3 and Jakarta 10 asap and leave behind in maintenance the existing stream.
However I feel that we are messing quite a lot with our releases and not communicating well enough about our plans as community. To me, it feels messy that we have a 8.45.0 release, followed by a 9.45 release in our first Apache release, and immediately after put 8.x (1.x for Kogito) in maintenance. I think we could step back and re-evaluate our strategy. Why not reset and focus only on Jakarta10 (and Quarkus/SpringBoot. 3.x) and cut it as 9.0? (yes, I’m aware that we had in recent past a 9.44.Alpha). There is no ideal situation here, but the current plans are quite hard to follow and a hard reset with everything moved to 9.0 in a new home makes me think that we have a good starting point. Wdyt? On Mon, Oct 16, 2023 at 6:54 AM Enrique Gonzalez Martinez < [email protected]> wrote: > +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 > > > > > > > > > >
