Hi everyone,
We have been reported of a critical bug in KieSession serialization that has
been fixed with this commit
https://github.com/apache/incubator-kie-drools/commit/f3179021b7e97499e77a79ddceec483f5d568449
For this reason we decided to backport this fix to the 8.x streams and drop a
+1
Mario
On 2024/03/19 14:11:30 Alex Porcelli wrote:
> With all the feedback from the proposal discussion [1], I am starting
> this official vote to accept the amended proposal to unblock Apache
> KIE 10.0.0 Release.
>
> Here [2] is the link for the final amended proposal.
>
> Please cast your
Huge +1 on this.
Mario
On 2024/02/27 03:32:09 Toshiya Kobayashi wrote:
> Hi,
>
> The current DRL parser is Antlr3 based and contains lots of hard-coded
> logic in generated java codes, so it's hard to maintain.
>
> for example)
>
Hi Alex,
Just to clarify the purposes of this effort and from where this originate,
consider that the development of this new ANTLR v4 based parser for the DRL
started even before the migration to Apache and its main goal was to support
the implementation of an LSP server that could allow to
> drools has `drools-reliability` component which persistence is pluggable.
> We have infinispan persistence and h2 persistence at the moment. If we want
> to make the version 10 release "minimal", shall we keep only the h2
> persistence and then move the infinispan persistence to another repo
>
Hi all,
It seems that we are finally ready to conclude the migration to Quarkus 3 and
the jakarta namespace. We're about to merge some last fixes in these hours, so
the plan is to wait the next nightly build and target tomorrow morning to start
finalizing the migration.
In particular what we
+1 on removing the .Final suffix.
Mario
On 2023/11/28 14:03:30 Alex Porcelli wrote:
> We already have defined that all projects/artifacts will be aligned on
> 10. However, we must still determine if we should use 10.0.0 or
> 10.0.0.Final.
>
> I might be ahead, but as we progress towards the
> * Quarkus version
>
> Tibor, Alex and Jason give +1 for LTS 3.2.
>
> Mario, WDYT?
>
> A) Complete Quarkus 3.5.2 migration anyway. After the migration done,
> create a Quarkus 3.2 LTS branch, too.
> B) Recreate the current migration PRs to meet Quarkus 3.2.
I just had a meeting with Alex
to specify that.
>
> 3) Spring Boot version
>
> Pere mentioned
>
> > my guts say that we should upgrade if we have the oportunity but I'm
> affraid it could add more pain.
>
> https://kie.zulipchat.com/#narrow/stream/381961-drools-dev/topic/Quarkus.203.2
> It would be best to agree on a branch name - if it's quarkus3 - and
> generate special pipelines for that branch. So that we have clear
> separation. It would require branching of whole groups of repositories
> (similarly as above - incubator-kie-kogito-apps and others).
Hi Jan,
I agree on
Hi all,
Sorry if I try to rush this, but weeks and months are passing and we really
really need to finalize the migration to Quarkus 3 asap.
Yesterday I created a branch of Drools that bumps it to the latest Quarkus
(3.5.2), see https://github.com/apache/incubator-kie-drools/compare/quarkus3
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
Hi all,
I wrote a first draft of the communicate for the new version numbering on which
we agreed:
https://docs.google.com/document/d/1UV79KnyhayF60pi67vG8sKUHHXLmWaRaH7mIji-n4GE/edit?usp=sharing
Anybody with that link should be able to view and add comments to that
document, then if you
+1 also for me. If we communicate this clearly this will give us a fresh start
that is totally coherent with the apache migration.
If it's ok for you, I can take care of starting writing down a short article to
explain the situation. For now I'll put it on a shared Google docs so everybody
> 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
eady 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 wrote:
>
> > > To me, it feels messy that we have a 8.45
> 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
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
Hi Alex,
Sorry if I'm reading and replying to this email with so much delay.
> • The other is from a PPMC member.
In all honesty this specific constraint seems unnecessarily and excessively
restrictive to me. I'm afraid that waiting for an approval from a so small
group of persons for all
19 matches
Mail list logo
