You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kie.apache.org by Mario Fusco <ma...@apache.org> on 2023/10/16 10:18:30 UTC
Move to Quarkus3/Jakarta + Quarkus extension for rules
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
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Jan Šťastný <js...@apache.org>.
Hello,
I might be ignorant of the history around branching, etc. But from the
pipelines I can see it's supposed to be an automatic action. Having said
that, I have not yet adjusted the pipeline configuration to use robot
account credentials that have push privilege. But it should not be an
enormous amount of work.
Thing is - if we branch manually, it might be kinda messy to once again
adjust the pipelines' config to the new branch (if relying on automation,
all should be adjusted accordingly when branching).
Drools could be a guinea pig of the pipeline adjustments and we would
hopefully soon be able to branch out using automation.
What do you think?
Regards
Jan
On Wed, 8 Nov 2023 at 10:49, Mario Fusco <ma...@apache.org> wrote:
> Hi all,
>
> I just have a call with Tibor and he told me that at the moment we are
> able to produce and deploy nightly builds but still we cannot drop a stable
> release.
>
> Regardless of this latest issue if possible I'd move forward branching 8.x
> and applying to main the openrewrite migration scripts one last time. In
> particular my suggestion is performing this migration and commit it on the
> main branch as it is, even if this will temporarily break the builds,
> otherwise it will be impossible to parallelize the work to finalize the
> migration itself.
>
> Please let me know if what I'm proposing is reasonable/feasible or if you
> have any better suggestion to move this forward as soon as possible.
>
> Thanks,
> Mario
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Mario Fusco <ma...@apache.org>.
Hi all,
I just have a call with Tibor and he told me that at the moment we are able to produce and deploy nightly builds but still we cannot drop a stable release.
Regardless of this latest issue if possible I'd move forward branching 8.x and applying to main the openrewrite migration scripts one last time. In particular my suggestion is performing this migration and commit it on the main branch as it is, even if this will temporarily break the builds, otherwise it will be impossible to parallelize the work to finalize the migration itself.
Please let me know if what I'm proposing is reasonable/feasible or if you have any better suggestion to move this forward as soon as possible.
Thanks,
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Tristan Radisson <ra...@apache.org>.
FYI, I created an epic some time ago about remaining tasks for Quarkus 3
stability: https://issues.redhat.com/browse/KOGITO-9475
Also, prepare my leave, I created some PRs to update to Quarkus 3.2.x:
https://github.com/apache/incubator-kie-issues/issues/533
Feel free to reuse them if needed and ask any questions
On Wed, Oct 18, 2023 at 4:14 PM Alex Porcelli <po...@apache.org> wrote:
> +1 for good comms; with that being said this is planned for phase 2… which
> I believe we can start it as soon as we get the builds properly in place :)
>
>
> On Wed, Oct 18, 2023 at 9:28 AM ricardo zanini fernandes <
> ricardozanini@gmail.com> wrote:
>
> > I don't oppose to have 10.x version for everything.
> >
> > What I'd like to see is clear communication to the community, no matter
> the
> > version name. So a website with a nice landing page, explaining each
> > "module/inner project" from KIE, use cases, guides, etc following the
> same
> > pattern.
> >
> > cheers!
> > --
> > Ricardo Zanini Fernandes
> > Vida longa e próspera.
> >
> >
> > On Tue, Oct 17, 2023 at 7:25 PM Alex Porcelli <al...@porcelli.me> wrote:
> >
> > > Jason,
> > >
> > > I think we’ll revamp jBPM, the same way SonataFlow has been.
> > >
> > > With that being said, I think this will take a little longer until we
> > > properly manage to make the necessary readjustment in the codebase
> > > structure. Unless we want hold for a longer time to release, what I
> > > personally think is not a great idea :)
> > >
> > >
> > >
> > >
> > > On Tue, Oct 17, 2023 at 6:14 PM Jason Porter <li...@apache.org>
> > > wrote:
> > >
> > > > On 2023/10/17 13:18:59 Mario Fusco wrote:
> > > > > > Well, Kogito 1.x depends on Drools 8.x, so there was already some
> > > > disparity
> > > > > > in versions...
> > > > >
> > > > > Disparity in versions is incidental and doesn't imply a different
> > > > lifecycle in this case. Actually what we did so far is always
> releasing
> > > > Drools and Kogito in parallel every 3 weeks at the end of each
> sprint.
> > > Now
> > > > we are at Drools 8.44 and Kogito 1.44 and the minor release numbers
> are
> > > not
> > > > aligned by coincidence.
> > > >
> > > > Does this also hold true for jBPM? I know we have not done a release
> of
> > > > jBPM for some time. Maybe the release at Apache would signify enough
> > of a
> > > > change for people to take notice again?
> > > >
> > > > >
> > > > > Given this premise I like the idea of a fresh start for versions
> > > > numbering and having exactly the same version numbers for both Drools
> > and
> > > > Kogito will help to get rid of any ambiguity and underline the
> > > relationship
> > > > between the 2.
> > > > >
> > > > > Mario
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> > >
> >
>
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Alex Porcelli <po...@apache.org>.
+1 for good comms; with that being said this is planned for phase 2… which
I believe we can start it as soon as we get the builds properly in place :)
On Wed, Oct 18, 2023 at 9:28 AM ricardo zanini fernandes <
ricardozanini@gmail.com> wrote:
> I don't oppose to have 10.x version for everything.
>
> What I'd like to see is clear communication to the community, no matter the
> version name. So a website with a nice landing page, explaining each
> "module/inner project" from KIE, use cases, guides, etc following the same
> pattern.
>
> cheers!
> --
> Ricardo Zanini Fernandes
> Vida longa e próspera.
>
>
> On Tue, Oct 17, 2023 at 7:25 PM Alex Porcelli <al...@porcelli.me> wrote:
>
> > Jason,
> >
> > I think we’ll revamp jBPM, the same way SonataFlow has been.
> >
> > With that being said, I think this will take a little longer until we
> > properly manage to make the necessary readjustment in the codebase
> > structure. Unless we want hold for a longer time to release, what I
> > personally think is not a great idea :)
> >
> >
> >
> >
> > On Tue, Oct 17, 2023 at 6:14 PM Jason Porter <li...@apache.org>
> > wrote:
> >
> > > On 2023/10/17 13:18:59 Mario Fusco wrote:
> > > > > Well, Kogito 1.x depends on Drools 8.x, so there was already some
> > > disparity
> > > > > in versions...
> > > >
> > > > Disparity in versions is incidental and doesn't imply a different
> > > lifecycle in this case. Actually what we did so far is always releasing
> > > Drools and Kogito in parallel every 3 weeks at the end of each sprint.
> > Now
> > > we are at Drools 8.44 and Kogito 1.44 and the minor release numbers are
> > not
> > > aligned by coincidence.
> > >
> > > Does this also hold true for jBPM? I know we have not done a release of
> > > jBPM for some time. Maybe the release at Apache would signify enough
> of a
> > > change for people to take notice again?
> > >
> > > >
> > > > Given this premise I like the idea of a fresh start for versions
> > > numbering and having exactly the same version numbers for both Drools
> and
> > > Kogito will help to get rid of any ambiguity and underline the
> > relationship
> > > between the 2.
> > > >
> > > > Mario
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
>
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by ricardo zanini fernandes <ri...@gmail.com>.
I don't oppose to have 10.x version for everything.
What I'd like to see is clear communication to the community, no matter the
version name. So a website with a nice landing page, explaining each
"module/inner project" from KIE, use cases, guides, etc following the same
pattern.
cheers!
--
Ricardo Zanini Fernandes
Vida longa e próspera.
On Tue, Oct 17, 2023 at 7:25 PM Alex Porcelli <al...@porcelli.me> wrote:
> Jason,
>
> I think we’ll revamp jBPM, the same way SonataFlow has been.
>
> With that being said, I think this will take a little longer until we
> properly manage to make the necessary readjustment in the codebase
> structure. Unless we want hold for a longer time to release, what I
> personally think is not a great idea :)
>
>
>
>
> On Tue, Oct 17, 2023 at 6:14 PM Jason Porter <li...@apache.org>
> wrote:
>
> > On 2023/10/17 13:18:59 Mario Fusco wrote:
> > > > Well, Kogito 1.x depends on Drools 8.x, so there was already some
> > disparity
> > > > in versions...
> > >
> > > Disparity in versions is incidental and doesn't imply a different
> > lifecycle in this case. Actually what we did so far is always releasing
> > Drools and Kogito in parallel every 3 weeks at the end of each sprint.
> Now
> > we are at Drools 8.44 and Kogito 1.44 and the minor release numbers are
> not
> > aligned by coincidence.
> >
> > Does this also hold true for jBPM? I know we have not done a release of
> > jBPM for some time. Maybe the release at Apache would signify enough of a
> > change for people to take notice again?
> >
> > >
> > > Given this premise I like the idea of a fresh start for versions
> > numbering and having exactly the same version numbers for both Drools and
> > Kogito will help to get rid of any ambiguity and underline the
> relationship
> > between the 2.
> > >
> > > Mario
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Alex Porcelli <al...@porcelli.me>.
Jason,
I think we’ll revamp jBPM, the same way SonataFlow has been.
With that being said, I think this will take a little longer until we
properly manage to make the necessary readjustment in the codebase
structure. Unless we want hold for a longer time to release, what I
personally think is not a great idea :)
On Tue, Oct 17, 2023 at 6:14 PM Jason Porter <li...@apache.org>
wrote:
> On 2023/10/17 13:18:59 Mario Fusco wrote:
> > > Well, Kogito 1.x depends on Drools 8.x, so there was already some
> disparity
> > > in versions...
> >
> > Disparity in versions is incidental and doesn't imply a different
> lifecycle in this case. Actually what we did so far is always releasing
> Drools and Kogito in parallel every 3 weeks at the end of each sprint. Now
> we are at Drools 8.44 and Kogito 1.44 and the minor release numbers are not
> aligned by coincidence.
>
> Does this also hold true for jBPM? I know we have not done a release of
> jBPM for some time. Maybe the release at Apache would signify enough of a
> change for people to take notice again?
>
> >
> > Given this premise I like the idea of a fresh start for versions
> numbering and having exactly the same version numbers for both Drools and
> Kogito will help to get rid of any ambiguity and underline the relationship
> between the 2.
> >
> > Mario
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Jason Porter <li...@apache.org>.
On 2023/10/17 13:18:59 Mario Fusco wrote:
> > Well, Kogito 1.x depends on Drools 8.x, so there was already some disparity
> > in versions...
>
> Disparity in versions is incidental and doesn't imply a different lifecycle in this case. Actually what we did so far is always releasing Drools and Kogito in parallel every 3 weeks at the end of each sprint. Now we are at Drools 8.44 and Kogito 1.44 and the minor release numbers are not aligned by coincidence.
Does this also hold true for jBPM? I know we have not done a release of jBPM for some time. Maybe the release at Apache would signify enough of a change for people to take notice again?
>
> Given this premise I like the idea of a fresh start for versions numbering and having exactly the same version numbers for both Drools and Kogito will help to get rid of any ambiguity and underline the relationship between the 2.
>
> Mario
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Mario Fusco <ma...@apache.org>.
> Well, Kogito 1.x depends on Drools 8.x, so there was already some disparity
> in versions...
Disparity in versions is incidental and doesn't imply a different lifecycle in this case. Actually what we did so far is always releasing Drools and Kogito in parallel every 3 weeks at the end of each sprint. Now we are at Drools 8.44 and Kogito 1.44 and the minor release numbers are not aligned by coincidence.
Given this premise I like the idea of a fresh start for versions numbering and having exactly the same version numbers for both Drools and Kogito will help to get rid of any ambiguity and underline the relationship between the 2.
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Alex Porcelli <al...@porcelli.me>.
Tristan,
If different components have their own release cycles, and their own LTS
versioning, it’ll require a lot of effort to build and maintain a support
matrix among components. I’d argue this would go against the initial Apache
KIE proposal of the unified family of technology.
There’s also the fact that we don’t have a dedicated CI/prod team, it’s all
voluntary and I don’t think we can afford such level of complexity.
In my opinion, unifying versioning and cycles, makes the comms much more
clear and crisp (to not mention more manageable), and also keep it aligned
with the Apache KIE proposal.
On Tue, Oct 17, 2023 at 3:48 AM Tristan Radisson <ra...@apache.org>
wrote:
> Well, Kogito 1.x depends on Drools 8.x, so there was already some disparity
> in versions...
>
> On Tue, Oct 17, 2023 at 9:44 AM Enrique Gonzalez Martinez <
> egonzalez@apache.org> wrote:
>
> > Releasing with the same version have been the norm in the community and
> all
> > versions were align, to the point that all projects were depending on
> > snapshots. If we are changing this philosophy now, we will need to depend
> > on final versions and will bring a bunch if ci changes.
> >
> > El mar, 17 oct 2023, 8:56, Tristan Radisson <ra...@apache.org>
> > escribió:
> >
> > > My 2 cents here:
> > >
> > > Drools, SonataFlow, jBPM, Kogito are "different" components of the KIE
> > > project and so you may have different release needs there.
> > > Having one version for all would mean that you release everything each
> > > time. This is quite huge ... Or you release differently but then your
> > > version will start to diverge ;)
> > >
> > >
> > > On Mon, Oct 16, 2023 at 10:53 PM Alex Porcelli <po...@apache.org>
> > > wrote:
> > >
> > > > My proposal is actually to simplify and align all KIE submodules on
> 10.
> > > >
> > > > The reasoning behind the proposal is that under Apache's perspective,
> > > > there's a single project called KIE, and all other brands are only
> > > > modules of it (Drools, SonataFlow, jBPM, Kogito, etc.).
> > > >
> > > > Although there's nothing that would force the use of the same version
> > > > among different modules, this is a way to simplify the communication
> > > > around Apache KIE.
> > > >
> > > > In the same way, I think we could simplify and have only Jakarta 10
> > > > released under the Apache Foundation.
> > > >
> > > >
> > > > On Mon, Oct 16, 2023 at 2:27 PM ricardo zanini fernandes
> > > > <ri...@gmail.com> wrote:
> > > > >
> > > > > So 10.0.x for Drools and 3.0.x for Kogito/Kie? We have only the
> > > > > 2.44.0.Alpha release for Kogito, thou. But 3.0.0 should send the
> > right
> > > > > message.
> > > > > Also, we need to rename a few artifacts from kogito- to kie- and
> > > > > kogito-serverless-workflow to sonataflow. Can we do it as a
> follow-up
> > > > task
> > > > > after this initial migration, and before release?
> > > > >
> > > > > Cheers!
> > > > > --
> > > > > Ricardo Zanini Fernandes
> > > > > Vida longa e próspera.
> > > > >
> > > > >
> > > > > On Mon, Oct 16, 2023 at 1:08 PM Jason Porter <
> > lightguardjp@apache.org>
> > > > > wrote:
> > > > >
> > > > > > +1 for version 10.
> > > > > >
> > > > > > For LTS reasons and ease of use, do we want to go with version 10
> > > > > > everywhere and release everything with the same version? I know
> > > > there's a
> > > > > > BOM, and maybe that makes this moot. Thoughts?
> > > > > >
> > > > > > On 2023/10/16 14:35:12 Alex Porcelli wrote:
> > > > > > > Thank you for the clarification of the implications to recycle
> > 9.x,
> > > > > > Mario!
> > > > > > >
> > > > > > > Given that situation, my personal preference, for better
> > > > communication
> > > > > > > sake, is to have a hard reset to 10.0 focused only on Jakarta
> 10.
> > > > > > >
> > > > > > > Maybe it's worth a new thread for sake of clarity? I can start
> > it.
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Oct 16, 2023 at 10:11 AM Mario Fusco <
> > > mariofusco@apache.org>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > Alex,
> > > > > > > >
> > > > > > > > The problem is not the use of LATEST (which is indeed
> > deprecated
> > > > and
> > > > > > hopefully nobody uses it anymore), but the fact that releasing a
> > > > > > 9.0.0.Final when the 9.44.0.Final will break maven implicit
> version
> > > > numbers
> > > > > > ordering and semantic versioning.
> > > > > > > >
> > > > > > > > Moreover this will be even more problematic and confusing for
> > > > users,
> > > > > > especially new ones. How do you choose the version of a
> dependency
> > > > that you
> > > > > > have to add for the first time into your project? Personally
> what I
> > > do
> > > > is
> > > > > > going to the Maven Central Repository Search website, doing a
> > search
> > > > for
> > > > > > the dependency I need and bringing in the very latest version
> > (unless
> > > > there
> > > > > > are very good reasons, like a known bug, not to do so). Now if
> I'd
> > do
> > > > this
> > > > > > exercise with drools I'd always bring in 9.44 even if there are
> new
> > > > > > versions available (but with a lower version number).
> > > > > > > >
> > > > > > > > If you really want a fresh start (and I could agree that it
> > could
> > > > be a
> > > > > > good idea at this point) then we should skip the 9 at all ( like
> > > > Windows
> > > > > > did so it could not be THAT bad :) ) and release a 10.0.0.Final.
> > > > > > > >
> > > > > > > > Mario
> > > > > > > >
> > > > > > > > On 2023/10/16 13:29:11 Alex Porcelli wrote:
> > > > > > > > > Mario,
> > > > > > > > >
> > > > > > > > > Thank you for the 9.44 reference, I though we had somehow
> an
> > > > Alpha
> > > > > > release
> > > > > > > > > and not a final one.
> > > > > > > > >
> > > > > > > > > With all pros and cons of the current situation (including
> > the
> > > > > > already
> > > > > > > > > published 9.44) - I’d still prefer a hard reset around 9.0
> > > > focused on
> > > > > > > > > Jakarta 10 only.
> > > > > > > > >
> > > > > > > > > In my opinion the hard reset on 9.0 with Jakarta 10
> > > > > > > > > outperforms the impact of the already existing 9.44
> release.
> > > > (It’s my
> > > > > > > > > understanding that the impact is for users that would use
> > > > -LATEST -
> > > > > > which
> > > > > > > > > is already considered a deprecated format anyway)
> > > > > > > > >
> > > > > > > > > On Mon, Oct 16, 2023 at 9:11 AM Mario Fusco <
> > > > mariofusco@apache.org>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > > 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).
> > > > > > > > > >
> > > > > > > > > > Hi Alex,
> > > > > > > > > >
> > > > > > > > > > What you suggested makes sense and as I wrote I'm equally
> > > > afraid
> > > > > > that
> > > > > > > > > > users may be confused around our versions numbering.
> > > > Unfortunately
> > > > > > I'm also
> > > > > > > > > > afraid that you missed that we already put out a
> > 9.44.0.Final
> > > > > > version (
> > > > > > > > > >
> > > https://central.sonatype.com/artifact/org.drools/drools-engine
> > > > )
> > > > > > that is
> > > > > > > > > > the result of that automatic migration of version 8.44 to
> > > > Quarkus
> > > > > > 3 and
> > > > > > > > > > Jakarta using that Openrewrite script. That's the reason
> > why
> > > I
> > > > > > think that
> > > > > > > > > > there aren't many alternatives other than continuing from
> > > > there.
> > > > > > Can you
> > > > > > > > > > think to any better solution?
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Mario
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> > >
> >
>
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Tristan Radisson <ra...@apache.org>.
Well, Kogito 1.x depends on Drools 8.x, so there was already some disparity
in versions...
On Tue, Oct 17, 2023 at 9:44 AM Enrique Gonzalez Martinez <
egonzalez@apache.org> wrote:
> Releasing with the same version have been the norm in the community and all
> versions were align, to the point that all projects were depending on
> snapshots. If we are changing this philosophy now, we will need to depend
> on final versions and will bring a bunch if ci changes.
>
> El mar, 17 oct 2023, 8:56, Tristan Radisson <ra...@apache.org>
> escribió:
>
> > My 2 cents here:
> >
> > Drools, SonataFlow, jBPM, Kogito are "different" components of the KIE
> > project and so you may have different release needs there.
> > Having one version for all would mean that you release everything each
> > time. This is quite huge ... Or you release differently but then your
> > version will start to diverge ;)
> >
> >
> > On Mon, Oct 16, 2023 at 10:53 PM Alex Porcelli <po...@apache.org>
> > wrote:
> >
> > > My proposal is actually to simplify and align all KIE submodules on 10.
> > >
> > > The reasoning behind the proposal is that under Apache's perspective,
> > > there's a single project called KIE, and all other brands are only
> > > modules of it (Drools, SonataFlow, jBPM, Kogito, etc.).
> > >
> > > Although there's nothing that would force the use of the same version
> > > among different modules, this is a way to simplify the communication
> > > around Apache KIE.
> > >
> > > In the same way, I think we could simplify and have only Jakarta 10
> > > released under the Apache Foundation.
> > >
> > >
> > > On Mon, Oct 16, 2023 at 2:27 PM ricardo zanini fernandes
> > > <ri...@gmail.com> wrote:
> > > >
> > > > So 10.0.x for Drools and 3.0.x for Kogito/Kie? We have only the
> > > > 2.44.0.Alpha release for Kogito, thou. But 3.0.0 should send the
> right
> > > > message.
> > > > Also, we need to rename a few artifacts from kogito- to kie- and
> > > > kogito-serverless-workflow to sonataflow. Can we do it as a follow-up
> > > task
> > > > after this initial migration, and before release?
> > > >
> > > > Cheers!
> > > > --
> > > > Ricardo Zanini Fernandes
> > > > Vida longa e próspera.
> > > >
> > > >
> > > > On Mon, Oct 16, 2023 at 1:08 PM Jason Porter <
> lightguardjp@apache.org>
> > > > wrote:
> > > >
> > > > > +1 for version 10.
> > > > >
> > > > > For LTS reasons and ease of use, do we want to go with version 10
> > > > > everywhere and release everything with the same version? I know
> > > there's a
> > > > > BOM, and maybe that makes this moot. Thoughts?
> > > > >
> > > > > On 2023/10/16 14:35:12 Alex Porcelli wrote:
> > > > > > Thank you for the clarification of the implications to recycle
> 9.x,
> > > > > Mario!
> > > > > >
> > > > > > Given that situation, my personal preference, for better
> > > communication
> > > > > > sake, is to have a hard reset to 10.0 focused only on Jakarta 10.
> > > > > >
> > > > > > Maybe it's worth a new thread for sake of clarity? I can start
> it.
> > > > > >
> > > > > >
> > > > > > On Mon, Oct 16, 2023 at 10:11 AM Mario Fusco <
> > mariofusco@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > > Alex,
> > > > > > >
> > > > > > > The problem is not the use of LATEST (which is indeed
> deprecated
> > > and
> > > > > hopefully nobody uses it anymore), but the fact that releasing a
> > > > > 9.0.0.Final when the 9.44.0.Final will break maven implicit version
> > > numbers
> > > > > ordering and semantic versioning.
> > > > > > >
> > > > > > > Moreover this will be even more problematic and confusing for
> > > users,
> > > > > especially new ones. How do you choose the version of a dependency
> > > that you
> > > > > have to add for the first time into your project? Personally what I
> > do
> > > is
> > > > > going to the Maven Central Repository Search website, doing a
> search
> > > for
> > > > > the dependency I need and bringing in the very latest version
> (unless
> > > there
> > > > > are very good reasons, like a known bug, not to do so). Now if I'd
> do
> > > this
> > > > > exercise with drools I'd always bring in 9.44 even if there are new
> > > > > versions available (but with a lower version number).
> > > > > > >
> > > > > > > If you really want a fresh start (and I could agree that it
> could
> > > be a
> > > > > good idea at this point) then we should skip the 9 at all ( like
> > > Windows
> > > > > did so it could not be THAT bad :) ) and release a 10.0.0.Final.
> > > > > > >
> > > > > > > Mario
> > > > > > >
> > > > > > > On 2023/10/16 13:29:11 Alex Porcelli wrote:
> > > > > > > > Mario,
> > > > > > > >
> > > > > > > > Thank you for the 9.44 reference, I though we had somehow an
> > > Alpha
> > > > > release
> > > > > > > > and not a final one.
> > > > > > > >
> > > > > > > > With all pros and cons of the current situation (including
> the
> > > > > already
> > > > > > > > published 9.44) - I’d still prefer a hard reset around 9.0
> > > focused on
> > > > > > > > Jakarta 10 only.
> > > > > > > >
> > > > > > > > In my opinion the hard reset on 9.0 with Jakarta 10
> > > > > > > > outperforms the impact of the already existing 9.44 release.
> > > (It’s my
> > > > > > > > understanding that the impact is for users that would use
> > > -LATEST -
> > > > > which
> > > > > > > > is already considered a deprecated format anyway)
> > > > > > > >
> > > > > > > > On Mon, Oct 16, 2023 at 9:11 AM Mario Fusco <
> > > mariofusco@apache.org>
> > > > > wrote:
> > > > > > > >
> > > > > > > > > > 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).
> > > > > > > > >
> > > > > > > > > Hi Alex,
> > > > > > > > >
> > > > > > > > > What you suggested makes sense and as I wrote I'm equally
> > > afraid
> > > > > that
> > > > > > > > > users may be confused around our versions numbering.
> > > Unfortunately
> > > > > I'm also
> > > > > > > > > afraid that you missed that we already put out a
> 9.44.0.Final
> > > > > version (
> > > > > > > > >
> > https://central.sonatype.com/artifact/org.drools/drools-engine
> > > )
> > > > > that is
> > > > > > > > > the result of that automatic migration of version 8.44 to
> > > Quarkus
> > > > > 3 and
> > > > > > > > > Jakarta using that Openrewrite script. That's the reason
> why
> > I
> > > > > think that
> > > > > > > > > there aren't many alternatives other than continuing from
> > > there.
> > > > > Can you
> > > > > > > > > think to any better solution?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Mario
> > > > > > > > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
>
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Enrique Gonzalez Martinez <eg...@apache.org>.
Releasing with the same version have been the norm in the community and all
versions were align, to the point that all projects were depending on
snapshots. If we are changing this philosophy now, we will need to depend
on final versions and will bring a bunch if ci changes.
El mar, 17 oct 2023, 8:56, Tristan Radisson <ra...@apache.org> escribió:
> My 2 cents here:
>
> Drools, SonataFlow, jBPM, Kogito are "different" components of the KIE
> project and so you may have different release needs there.
> Having one version for all would mean that you release everything each
> time. This is quite huge ... Or you release differently but then your
> version will start to diverge ;)
>
>
> On Mon, Oct 16, 2023 at 10:53 PM Alex Porcelli <po...@apache.org>
> wrote:
>
> > My proposal is actually to simplify and align all KIE submodules on 10.
> >
> > The reasoning behind the proposal is that under Apache's perspective,
> > there's a single project called KIE, and all other brands are only
> > modules of it (Drools, SonataFlow, jBPM, Kogito, etc.).
> >
> > Although there's nothing that would force the use of the same version
> > among different modules, this is a way to simplify the communication
> > around Apache KIE.
> >
> > In the same way, I think we could simplify and have only Jakarta 10
> > released under the Apache Foundation.
> >
> >
> > On Mon, Oct 16, 2023 at 2:27 PM ricardo zanini fernandes
> > <ri...@gmail.com> wrote:
> > >
> > > So 10.0.x for Drools and 3.0.x for Kogito/Kie? We have only the
> > > 2.44.0.Alpha release for Kogito, thou. But 3.0.0 should send the right
> > > message.
> > > Also, we need to rename a few artifacts from kogito- to kie- and
> > > kogito-serverless-workflow to sonataflow. Can we do it as a follow-up
> > task
> > > after this initial migration, and before release?
> > >
> > > Cheers!
> > > --
> > > Ricardo Zanini Fernandes
> > > Vida longa e próspera.
> > >
> > >
> > > On Mon, Oct 16, 2023 at 1:08 PM Jason Porter <li...@apache.org>
> > > wrote:
> > >
> > > > +1 for version 10.
> > > >
> > > > For LTS reasons and ease of use, do we want to go with version 10
> > > > everywhere and release everything with the same version? I know
> > there's a
> > > > BOM, and maybe that makes this moot. Thoughts?
> > > >
> > > > On 2023/10/16 14:35:12 Alex Porcelli wrote:
> > > > > Thank you for the clarification of the implications to recycle 9.x,
> > > > Mario!
> > > > >
> > > > > Given that situation, my personal preference, for better
> > communication
> > > > > sake, is to have a hard reset to 10.0 focused only on Jakarta 10.
> > > > >
> > > > > Maybe it's worth a new thread for sake of clarity? I can start it.
> > > > >
> > > > >
> > > > > On Mon, Oct 16, 2023 at 10:11 AM Mario Fusco <
> mariofusco@apache.org>
> > > > wrote:
> > > > > >
> > > > > > Alex,
> > > > > >
> > > > > > The problem is not the use of LATEST (which is indeed deprecated
> > and
> > > > hopefully nobody uses it anymore), but the fact that releasing a
> > > > 9.0.0.Final when the 9.44.0.Final will break maven implicit version
> > numbers
> > > > ordering and semantic versioning.
> > > > > >
> > > > > > Moreover this will be even more problematic and confusing for
> > users,
> > > > especially new ones. How do you choose the version of a dependency
> > that you
> > > > have to add for the first time into your project? Personally what I
> do
> > is
> > > > going to the Maven Central Repository Search website, doing a search
> > for
> > > > the dependency I need and bringing in the very latest version (unless
> > there
> > > > are very good reasons, like a known bug, not to do so). Now if I'd do
> > this
> > > > exercise with drools I'd always bring in 9.44 even if there are new
> > > > versions available (but with a lower version number).
> > > > > >
> > > > > > If you really want a fresh start (and I could agree that it could
> > be a
> > > > good idea at this point) then we should skip the 9 at all ( like
> > Windows
> > > > did so it could not be THAT bad :) ) and release a 10.0.0.Final.
> > > > > >
> > > > > > Mario
> > > > > >
> > > > > > On 2023/10/16 13:29:11 Alex Porcelli wrote:
> > > > > > > Mario,
> > > > > > >
> > > > > > > Thank you for the 9.44 reference, I though we had somehow an
> > Alpha
> > > > release
> > > > > > > and not a final one.
> > > > > > >
> > > > > > > With all pros and cons of the current situation (including the
> > > > already
> > > > > > > published 9.44) - I’d still prefer a hard reset around 9.0
> > focused on
> > > > > > > Jakarta 10 only.
> > > > > > >
> > > > > > > In my opinion the hard reset on 9.0 with Jakarta 10
> > > > > > > outperforms the impact of the already existing 9.44 release.
> > (It’s my
> > > > > > > understanding that the impact is for users that would use
> > -LATEST -
> > > > which
> > > > > > > is already considered a deprecated format anyway)
> > > > > > >
> > > > > > > On Mon, Oct 16, 2023 at 9:11 AM Mario Fusco <
> > mariofusco@apache.org>
> > > > wrote:
> > > > > > >
> > > > > > > > > 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).
> > > > > > > >
> > > > > > > > Hi Alex,
> > > > > > > >
> > > > > > > > What you suggested makes sense and as I wrote I'm equally
> > afraid
> > > > that
> > > > > > > > users may be confused around our versions numbering.
> > Unfortunately
> > > > I'm also
> > > > > > > > afraid that you missed that we already put out a 9.44.0.Final
> > > > version (
> > > > > > > >
> https://central.sonatype.com/artifact/org.drools/drools-engine
> > )
> > > > that is
> > > > > > > > the result of that automatic migration of version 8.44 to
> > Quarkus
> > > > 3 and
> > > > > > > > Jakarta using that Openrewrite script. That's the reason why
> I
> > > > think that
> > > > > > > > there aren't many alternatives other than continuing from
> > there.
> > > > Can you
> > > > > > > > think to any better solution?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Mario
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Tristan Radisson <ra...@apache.org>.
My 2 cents here:
Drools, SonataFlow, jBPM, Kogito are "different" components of the KIE
project and so you may have different release needs there.
Having one version for all would mean that you release everything each
time. This is quite huge ... Or you release differently but then your
version will start to diverge ;)
On Mon, Oct 16, 2023 at 10:53 PM Alex Porcelli <po...@apache.org> wrote:
> My proposal is actually to simplify and align all KIE submodules on 10.
>
> The reasoning behind the proposal is that under Apache's perspective,
> there's a single project called KIE, and all other brands are only
> modules of it (Drools, SonataFlow, jBPM, Kogito, etc.).
>
> Although there's nothing that would force the use of the same version
> among different modules, this is a way to simplify the communication
> around Apache KIE.
>
> In the same way, I think we could simplify and have only Jakarta 10
> released under the Apache Foundation.
>
>
> On Mon, Oct 16, 2023 at 2:27 PM ricardo zanini fernandes
> <ri...@gmail.com> wrote:
> >
> > So 10.0.x for Drools and 3.0.x for Kogito/Kie? We have only the
> > 2.44.0.Alpha release for Kogito, thou. But 3.0.0 should send the right
> > message.
> > Also, we need to rename a few artifacts from kogito- to kie- and
> > kogito-serverless-workflow to sonataflow. Can we do it as a follow-up
> task
> > after this initial migration, and before release?
> >
> > Cheers!
> > --
> > Ricardo Zanini Fernandes
> > Vida longa e próspera.
> >
> >
> > On Mon, Oct 16, 2023 at 1:08 PM Jason Porter <li...@apache.org>
> > wrote:
> >
> > > +1 for version 10.
> > >
> > > For LTS reasons and ease of use, do we want to go with version 10
> > > everywhere and release everything with the same version? I know
> there's a
> > > BOM, and maybe that makes this moot. Thoughts?
> > >
> > > On 2023/10/16 14:35:12 Alex Porcelli wrote:
> > > > Thank you for the clarification of the implications to recycle 9.x,
> > > Mario!
> > > >
> > > > Given that situation, my personal preference, for better
> communication
> > > > sake, is to have a hard reset to 10.0 focused only on Jakarta 10.
> > > >
> > > > Maybe it's worth a new thread for sake of clarity? I can start it.
> > > >
> > > >
> > > > On Mon, Oct 16, 2023 at 10:11 AM Mario Fusco <ma...@apache.org>
> > > wrote:
> > > > >
> > > > > Alex,
> > > > >
> > > > > The problem is not the use of LATEST (which is indeed deprecated
> and
> > > hopefully nobody uses it anymore), but the fact that releasing a
> > > 9.0.0.Final when the 9.44.0.Final will break maven implicit version
> numbers
> > > ordering and semantic versioning.
> > > > >
> > > > > Moreover this will be even more problematic and confusing for
> users,
> > > especially new ones. How do you choose the version of a dependency
> that you
> > > have to add for the first time into your project? Personally what I do
> is
> > > going to the Maven Central Repository Search website, doing a search
> for
> > > the dependency I need and bringing in the very latest version (unless
> there
> > > are very good reasons, like a known bug, not to do so). Now if I'd do
> this
> > > exercise with drools I'd always bring in 9.44 even if there are new
> > > versions available (but with a lower version number).
> > > > >
> > > > > If you really want a fresh start (and I could agree that it could
> be a
> > > good idea at this point) then we should skip the 9 at all ( like
> Windows
> > > did so it could not be THAT bad :) ) and release a 10.0.0.Final.
> > > > >
> > > > > Mario
> > > > >
> > > > > On 2023/10/16 13:29:11 Alex Porcelli wrote:
> > > > > > Mario,
> > > > > >
> > > > > > Thank you for the 9.44 reference, I though we had somehow an
> Alpha
> > > release
> > > > > > and not a final one.
> > > > > >
> > > > > > With all pros and cons of the current situation (including the
> > > already
> > > > > > published 9.44) - I’d still prefer a hard reset around 9.0
> focused on
> > > > > > Jakarta 10 only.
> > > > > >
> > > > > > In my opinion the hard reset on 9.0 with Jakarta 10
> > > > > > outperforms the impact of the already existing 9.44 release.
> (It’s my
> > > > > > understanding that the impact is for users that would use
> -LATEST -
> > > which
> > > > > > is already considered a deprecated format anyway)
> > > > > >
> > > > > > On Mon, Oct 16, 2023 at 9:11 AM Mario Fusco <
> mariofusco@apache.org>
> > > wrote:
> > > > > >
> > > > > > > > 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).
> > > > > > >
> > > > > > > Hi Alex,
> > > > > > >
> > > > > > > What you suggested makes sense and as I wrote I'm equally
> afraid
> > > that
> > > > > > > users may be confused around our versions numbering.
> Unfortunately
> > > I'm also
> > > > > > > afraid that you missed that we already put out a 9.44.0.Final
> > > version (
> > > > > > > https://central.sonatype.com/artifact/org.drools/drools-engine
> )
> > > that is
> > > > > > > the result of that automatic migration of version 8.44 to
> Quarkus
> > > 3 and
> > > > > > > Jakarta using that Openrewrite script. That's the reason why I
> > > think that
> > > > > > > there aren't many alternatives other than continuing from
> there.
> > > Can you
> > > > > > > think to any better solution?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Mario
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Alex Porcelli <po...@apache.org>.
My proposal is actually to simplify and align all KIE submodules on 10.
The reasoning behind the proposal is that under Apache's perspective,
there's a single project called KIE, and all other brands are only
modules of it (Drools, SonataFlow, jBPM, Kogito, etc.).
Although there's nothing that would force the use of the same version
among different modules, this is a way to simplify the communication
around Apache KIE.
In the same way, I think we could simplify and have only Jakarta 10
released under the Apache Foundation.
On Mon, Oct 16, 2023 at 2:27 PM ricardo zanini fernandes
<ri...@gmail.com> wrote:
>
> So 10.0.x for Drools and 3.0.x for Kogito/Kie? We have only the
> 2.44.0.Alpha release for Kogito, thou. But 3.0.0 should send the right
> message.
> Also, we need to rename a few artifacts from kogito- to kie- and
> kogito-serverless-workflow to sonataflow. Can we do it as a follow-up task
> after this initial migration, and before release?
>
> Cheers!
> --
> Ricardo Zanini Fernandes
> Vida longa e próspera.
>
>
> On Mon, Oct 16, 2023 at 1:08 PM Jason Porter <li...@apache.org>
> wrote:
>
> > +1 for version 10.
> >
> > For LTS reasons and ease of use, do we want to go with version 10
> > everywhere and release everything with the same version? I know there's a
> > BOM, and maybe that makes this moot. Thoughts?
> >
> > On 2023/10/16 14:35:12 Alex Porcelli wrote:
> > > Thank you for the clarification of the implications to recycle 9.x,
> > Mario!
> > >
> > > Given that situation, my personal preference, for better communication
> > > sake, is to have a hard reset to 10.0 focused only on Jakarta 10.
> > >
> > > Maybe it's worth a new thread for sake of clarity? I can start it.
> > >
> > >
> > > On Mon, Oct 16, 2023 at 10:11 AM Mario Fusco <ma...@apache.org>
> > wrote:
> > > >
> > > > Alex,
> > > >
> > > > The problem is not the use of LATEST (which is indeed deprecated and
> > hopefully nobody uses it anymore), but the fact that releasing a
> > 9.0.0.Final when the 9.44.0.Final will break maven implicit version numbers
> > ordering and semantic versioning.
> > > >
> > > > Moreover this will be even more problematic and confusing for users,
> > especially new ones. How do you choose the version of a dependency that you
> > have to add for the first time into your project? Personally what I do is
> > going to the Maven Central Repository Search website, doing a search for
> > the dependency I need and bringing in the very latest version (unless there
> > are very good reasons, like a known bug, not to do so). Now if I'd do this
> > exercise with drools I'd always bring in 9.44 even if there are new
> > versions available (but with a lower version number).
> > > >
> > > > If you really want a fresh start (and I could agree that it could be a
> > good idea at this point) then we should skip the 9 at all ( like Windows
> > did so it could not be THAT bad :) ) and release a 10.0.0.Final.
> > > >
> > > > Mario
> > > >
> > > > On 2023/10/16 13:29:11 Alex Porcelli wrote:
> > > > > Mario,
> > > > >
> > > > > Thank you for the 9.44 reference, I though we had somehow an Alpha
> > release
> > > > > and not a final one.
> > > > >
> > > > > With all pros and cons of the current situation (including the
> > already
> > > > > published 9.44) - I’d still prefer a hard reset around 9.0 focused on
> > > > > Jakarta 10 only.
> > > > >
> > > > > In my opinion the hard reset on 9.0 with Jakarta 10
> > > > > outperforms the impact of the already existing 9.44 release. (It’s my
> > > > > understanding that the impact is for users that would use -LATEST -
> > which
> > > > > is already considered a deprecated format anyway)
> > > > >
> > > > > On Mon, Oct 16, 2023 at 9:11 AM Mario Fusco <ma...@apache.org>
> > wrote:
> > > > >
> > > > > > > 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).
> > > > > >
> > > > > > Hi Alex,
> > > > > >
> > > > > > What you suggested makes sense and as I wrote I'm equally afraid
> > that
> > > > > > users may be confused around our versions numbering. Unfortunately
> > I'm also
> > > > > > afraid that you missed that we already put out a 9.44.0.Final
> > version (
> > > > > > https://central.sonatype.com/artifact/org.drools/drools-engine )
> > that is
> > > > > > the result of that automatic migration of version 8.44 to Quarkus
> > 3 and
> > > > > > Jakarta using that Openrewrite script. That's the reason why I
> > think that
> > > > > > there aren't many alternatives other than continuing from there.
> > Can you
> > > > > > think to any better solution?
> > > > > >
> > > > > > Thanks,
> > > > > > Mario
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by ricardo zanini fernandes <ri...@gmail.com>.
So 10.0.x for Drools and 3.0.x for Kogito/Kie? We have only the
2.44.0.Alpha release for Kogito, thou. But 3.0.0 should send the right
message.
Also, we need to rename a few artifacts from kogito- to kie- and
kogito-serverless-workflow to sonataflow. Can we do it as a follow-up task
after this initial migration, and before release?
Cheers!
--
Ricardo Zanini Fernandes
Vida longa e próspera.
On Mon, Oct 16, 2023 at 1:08 PM Jason Porter <li...@apache.org>
wrote:
> +1 for version 10.
>
> For LTS reasons and ease of use, do we want to go with version 10
> everywhere and release everything with the same version? I know there's a
> BOM, and maybe that makes this moot. Thoughts?
>
> On 2023/10/16 14:35:12 Alex Porcelli wrote:
> > Thank you for the clarification of the implications to recycle 9.x,
> Mario!
> >
> > Given that situation, my personal preference, for better communication
> > sake, is to have a hard reset to 10.0 focused only on Jakarta 10.
> >
> > Maybe it's worth a new thread for sake of clarity? I can start it.
> >
> >
> > On Mon, Oct 16, 2023 at 10:11 AM Mario Fusco <ma...@apache.org>
> wrote:
> > >
> > > Alex,
> > >
> > > The problem is not the use of LATEST (which is indeed deprecated and
> hopefully nobody uses it anymore), but the fact that releasing a
> 9.0.0.Final when the 9.44.0.Final will break maven implicit version numbers
> ordering and semantic versioning.
> > >
> > > Moreover this will be even more problematic and confusing for users,
> especially new ones. How do you choose the version of a dependency that you
> have to add for the first time into your project? Personally what I do is
> going to the Maven Central Repository Search website, doing a search for
> the dependency I need and bringing in the very latest version (unless there
> are very good reasons, like a known bug, not to do so). Now if I'd do this
> exercise with drools I'd always bring in 9.44 even if there are new
> versions available (but with a lower version number).
> > >
> > > If you really want a fresh start (and I could agree that it could be a
> good idea at this point) then we should skip the 9 at all ( like Windows
> did so it could not be THAT bad :) ) and release a 10.0.0.Final.
> > >
> > > Mario
> > >
> > > On 2023/10/16 13:29:11 Alex Porcelli wrote:
> > > > Mario,
> > > >
> > > > Thank you for the 9.44 reference, I though we had somehow an Alpha
> release
> > > > and not a final one.
> > > >
> > > > With all pros and cons of the current situation (including the
> already
> > > > published 9.44) - I’d still prefer a hard reset around 9.0 focused on
> > > > Jakarta 10 only.
> > > >
> > > > In my opinion the hard reset on 9.0 with Jakarta 10
> > > > outperforms the impact of the already existing 9.44 release. (It’s my
> > > > understanding that the impact is for users that would use -LATEST -
> which
> > > > is already considered a deprecated format anyway)
> > > >
> > > > On Mon, Oct 16, 2023 at 9:11 AM Mario Fusco <ma...@apache.org>
> wrote:
> > > >
> > > > > > 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).
> > > > >
> > > > > Hi Alex,
> > > > >
> > > > > What you suggested makes sense and as I wrote I'm equally afraid
> that
> > > > > users may be confused around our versions numbering. Unfortunately
> I'm also
> > > > > afraid that you missed that we already put out a 9.44.0.Final
> version (
> > > > > https://central.sonatype.com/artifact/org.drools/drools-engine )
> that is
> > > > > the result of that automatic migration of version 8.44 to Quarkus
> 3 and
> > > > > Jakarta using that Openrewrite script. That's the reason why I
> think that
> > > > > there aren't many alternatives other than continuing from there.
> Can you
> > > > > think to any better solution?
> > > > >
> > > > > Thanks,
> > > > > Mario
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Jason Porter <li...@apache.org>.
+1 for version 10.
For LTS reasons and ease of use, do we want to go with version 10 everywhere and release everything with the same version? I know there's a BOM, and maybe that makes this moot. Thoughts?
On 2023/10/16 14:35:12 Alex Porcelli wrote:
> Thank you for the clarification of the implications to recycle 9.x, Mario!
>
> Given that situation, my personal preference, for better communication
> sake, is to have a hard reset to 10.0 focused only on Jakarta 10.
>
> Maybe it's worth a new thread for sake of clarity? I can start it.
>
>
> On Mon, Oct 16, 2023 at 10:11 AM Mario Fusco <ma...@apache.org> wrote:
> >
> > Alex,
> >
> > The problem is not the use of LATEST (which is indeed deprecated and hopefully nobody uses it anymore), but the fact that releasing a 9.0.0.Final when the 9.44.0.Final will break maven implicit version numbers ordering and semantic versioning.
> >
> > Moreover this will be even more problematic and confusing for users, especially new ones. How do you choose the version of a dependency that you have to add for the first time into your project? Personally what I do is going to the Maven Central Repository Search website, doing a search for the dependency I need and bringing in the very latest version (unless there are very good reasons, like a known bug, not to do so). Now if I'd do this exercise with drools I'd always bring in 9.44 even if there are new versions available (but with a lower version number).
> >
> > If you really want a fresh start (and I could agree that it could be a good idea at this point) then we should skip the 9 at all ( like Windows did so it could not be THAT bad :) ) and release a 10.0.0.Final.
> >
> > Mario
> >
> > On 2023/10/16 13:29:11 Alex Porcelli wrote:
> > > Mario,
> > >
> > > Thank you for the 9.44 reference, I though we had somehow an Alpha release
> > > and not a final one.
> > >
> > > With all pros and cons of the current situation (including the already
> > > published 9.44) - I’d still prefer a hard reset around 9.0 focused on
> > > Jakarta 10 only.
> > >
> > > In my opinion the hard reset on 9.0 with Jakarta 10
> > > outperforms the impact of the already existing 9.44 release. (It’s my
> > > understanding that the impact is for users that would use -LATEST - which
> > > is already considered a deprecated format anyway)
> > >
> > > On Mon, Oct 16, 2023 at 9:11 AM Mario Fusco <ma...@apache.org> wrote:
> > >
> > > > > 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).
> > > >
> > > > Hi Alex,
> > > >
> > > > What you suggested makes sense and as I wrote I'm equally afraid that
> > > > users may be confused around our versions numbering. Unfortunately I'm also
> > > > afraid that you missed that we already put out a 9.44.0.Final version (
> > > > https://central.sonatype.com/artifact/org.drools/drools-engine ) that is
> > > > the result of that automatic migration of version 8.44 to Quarkus 3 and
> > > > Jakarta using that Openrewrite script. That's the reason why I think that
> > > > there aren't many alternatives other than continuing from there. Can you
> > > > think to any better solution?
> > > >
> > > > Thanks,
> > > > Mario
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Alex Porcelli <po...@apache.org>.
Thank you for the clarification of the implications to recycle 9.x, Mario!
Given that situation, my personal preference, for better communication
sake, is to have a hard reset to 10.0 focused only on Jakarta 10.
Maybe it's worth a new thread for sake of clarity? I can start it.
On Mon, Oct 16, 2023 at 10:11 AM Mario Fusco <ma...@apache.org> wrote:
>
> Alex,
>
> The problem is not the use of LATEST (which is indeed deprecated and hopefully nobody uses it anymore), but the fact that releasing a 9.0.0.Final when the 9.44.0.Final will break maven implicit version numbers ordering and semantic versioning.
>
> Moreover this will be even more problematic and confusing for users, especially new ones. How do you choose the version of a dependency that you have to add for the first time into your project? Personally what I do is going to the Maven Central Repository Search website, doing a search for the dependency I need and bringing in the very latest version (unless there are very good reasons, like a known bug, not to do so). Now if I'd do this exercise with drools I'd always bring in 9.44 even if there are new versions available (but with a lower version number).
>
> If you really want a fresh start (and I could agree that it could be a good idea at this point) then we should skip the 9 at all ( like Windows did so it could not be THAT bad :) ) and release a 10.0.0.Final.
>
> Mario
>
> On 2023/10/16 13:29:11 Alex Porcelli wrote:
> > Mario,
> >
> > Thank you for the 9.44 reference, I though we had somehow an Alpha release
> > and not a final one.
> >
> > With all pros and cons of the current situation (including the already
> > published 9.44) - I’d still prefer a hard reset around 9.0 focused on
> > Jakarta 10 only.
> >
> > In my opinion the hard reset on 9.0 with Jakarta 10
> > outperforms the impact of the already existing 9.44 release. (It’s my
> > understanding that the impact is for users that would use -LATEST - which
> > is already considered a deprecated format anyway)
> >
> > On Mon, Oct 16, 2023 at 9:11 AM Mario Fusco <ma...@apache.org> wrote:
> >
> > > > 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).
> > >
> > > Hi Alex,
> > >
> > > What you suggested makes sense and as I wrote I'm equally afraid that
> > > users may be confused around our versions numbering. Unfortunately I'm also
> > > afraid that you missed that we already put out a 9.44.0.Final version (
> > > https://central.sonatype.com/artifact/org.drools/drools-engine ) that is
> > > the result of that automatic migration of version 8.44 to Quarkus 3 and
> > > Jakarta using that Openrewrite script. That's the reason why I think that
> > > there aren't many alternatives other than continuing from there. Can you
> > > think to any better solution?
> > >
> > > Thanks,
> > > Mario
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Mario Fusco <ma...@apache.org>.
Alex,
The problem is not the use of LATEST (which is indeed deprecated and hopefully nobody uses it anymore), but the fact that releasing a 9.0.0.Final when the 9.44.0.Final will break maven implicit version numbers ordering and semantic versioning.
Moreover this will be even more problematic and confusing for users, especially new ones. How do you choose the version of a dependency that you have to add for the first time into your project? Personally what I do is going to the Maven Central Repository Search website, doing a search for the dependency I need and bringing in the very latest version (unless there are very good reasons, like a known bug, not to do so). Now if I'd do this exercise with drools I'd always bring in 9.44 even if there are new versions available (but with a lower version number).
If you really want a fresh start (and I could agree that it could be a good idea at this point) then we should skip the 9 at all ( like Windows did so it could not be THAT bad :) ) and release a 10.0.0.Final.
Mario
On 2023/10/16 13:29:11 Alex Porcelli wrote:
> Mario,
>
> Thank you for the 9.44 reference, I though we had somehow an Alpha release
> and not a final one.
>
> With all pros and cons of the current situation (including the already
> published 9.44) - I’d still prefer a hard reset around 9.0 focused on
> Jakarta 10 only.
>
> In my opinion the hard reset on 9.0 with Jakarta 10
> outperforms the impact of the already existing 9.44 release. (It’s my
> understanding that the impact is for users that would use -LATEST - which
> is already considered a deprecated format anyway)
>
> On Mon, Oct 16, 2023 at 9:11 AM Mario Fusco <ma...@apache.org> wrote:
>
> > > 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).
> >
> > Hi Alex,
> >
> > What you suggested makes sense and as I wrote I'm equally afraid that
> > users may be confused around our versions numbering. Unfortunately I'm also
> > afraid that you missed that we already put out a 9.44.0.Final version (
> > https://central.sonatype.com/artifact/org.drools/drools-engine ) that is
> > the result of that automatic migration of version 8.44 to Quarkus 3 and
> > Jakarta using that Openrewrite script. That's the reason why I think that
> > there aren't many alternatives other than continuing from there. Can you
> > think to any better solution?
> >
> > Thanks,
> > Mario
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Alex Porcelli <po...@apache.org>.
Mario,
Thank you for the 9.44 reference, I though we had somehow an Alpha release
and not a final one.
With all pros and cons of the current situation (including the already
published 9.44) - I’d still prefer a hard reset around 9.0 focused on
Jakarta 10 only.
In my opinion the hard reset on 9.0 with Jakarta 10
outperforms the impact of the already existing 9.44 release. (It’s my
understanding that the impact is for users that would use -LATEST - which
is already considered a deprecated format anyway)
On Mon, Oct 16, 2023 at 9:11 AM Mario Fusco <ma...@apache.org> wrote:
> > 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).
>
> Hi Alex,
>
> What you suggested makes sense and as I wrote I'm equally afraid that
> users may be confused around our versions numbering. Unfortunately I'm also
> afraid that you missed that we already put out a 9.44.0.Final version (
> https://central.sonatype.com/artifact/org.drools/drools-engine ) that is
> the result of that automatic migration of version 8.44 to Quarkus 3 and
> Jakarta using that Openrewrite script. That's the reason why I think that
> there aren't many alternatives other than continuing from there. Can you
> think to any better solution?
>
> Thanks,
> Mario
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Mario Fusco <ma...@apache.org>.
> 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).
Hi Alex,
What you suggested makes sense and as I wrote I'm equally afraid that users may be confused around our versions numbering. Unfortunately I'm also afraid that you missed that we already put out a 9.44.0.Final version ( https://central.sonatype.com/artifact/org.drools/drools-engine ) that is the result of that automatic migration of version 8.44 to Quarkus 3 and Jakarta using that Openrewrite script. That's the reason why I think that there aren't many alternatives other than continuing from there. Can you think to any better solution?
Thanks,
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Alex Porcelli <po...@apache.org>.
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 <
egonzalez@apache.org> wrote:
> +1
>
> El lun, 16 oct 2023, 12:53, Pere Fernandez <pe...@gmail.com>
> 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 <kr...@gmail.com>
> > 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 <ma...@apache.org>
> > > 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
> > > >
> > >
> >
>
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Enrique Gonzalez Martinez <eg...@apache.org>.
+1
El lun, 16 oct 2023, 12:53, Pere Fernandez <pe...@gmail.com>
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 <kr...@gmail.com>
> 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 <ma...@apache.org>
> > 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
> > >
> >
>
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Pere Fernandez <pe...@gmail.com>.
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 <kr...@gmail.com>
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 <ma...@apache.org>
> 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
> >
>
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Kris Verlaenen <kr...@gmail.com>.
+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 <ma...@apache.org> 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
>
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Luca Molteni <lm...@redhat.com>.
> On 16 Oct 2023, at 12:18, Mario Fusco <ma...@apache.org> wrote:
>
> 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.
Good idea +1
Luca
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: Move to Quarkus3/Jakarta + Quarkus extension for rules
Posted by Matteo Mortari <ma...@gmail.com>.
+1 to Mario's proposal, sounds right to me
On Mon, 16 Oct 2023 at 12:20, Mario Fusco <ma...@apache.org> 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
>
--
Matteo Mortari
youtube.com/@MatteoMortari
linkedin.com/in/matteomortari