Dominik and Ricardo, I understand your concern with removing features from users. Too much has grown around the circular dependency we had between `kogito-apps` and `kie-tools`. We're fixing it now, and it is a challenging task.
Rather than stating the "need" of `kogito-images` depending on `kie-tools`, let's keep the focus on the end result. IMHO it is irrelevant on which repo something is hosted, as long as we can do atomic releases and kick-off our release train with Apache KIE 10. That means defining a clear topology of repos during an Apache KIE build, which, by definition, can't contain cycles. Now, `kogito-images` either is part of the `drools` and `kogito-*` streams, or it's not. This PR [1] https://github.com/apache/incubator-kie-kogito-images/pull/1734 introduces a cycle, even without the changes proposed by me on the first email of this thread, so merging this PR would be introducing a blocker for the Apache KIE 10 release (and for future releases too). If we really wanted to have `kogito-images` depending on `kie-tools`, though, we would need to: 1. Make sure `kie-tools` doesn't depend on `kogito-images`; 2. Create a third development stream, just for `kogito-images`, leaving a buffer for `kogito-images` to be updated with the latest `kie-tools` version during a release. Analogous to what we do with `kie-tools` and the `drools` and `kogito-*` stream; 3. Create a mechanism to do timestamped SNAPSHOT releases of `kie-tools`, analogous to what we have on the `drools` and `kogito-*` streams now. This, IMHO, introduces a lot more complexity to our already convoluted release process, so I wouldn't go on that route. With all that said, and to be clear regarding the topology of the repository, to successfully build and release Apache KIE 10, we need to take all 22 repositories [1] we have in Apache right now, and sort them in a way that we can build them one by one, only once, without referencing older versions of any 1st-party package/module/image/artifact. We can't think about our repos in the same way we used to. KIE Tools won't have a release published before nor after a Drools or Kogito Runtimes release. Everything will be released at the same time. That's the mindset shift we all need to get used to if we want to do atomic releases of Apache KIE. I hope it is clearer now why we can't have `kogito-images` depending on `kie-tools` if `kogito-images` continues to be part of the `drools` and `kogito-*` development streams. The way I see it, Dominik came to this mail thread with an important and valid concern, which now we need to solve together, as a community. I'll keep my suggestions of either moving the image from `kogito-images` to `kie-tools`, or removing the dependency of SWF Quarkus Dev UI from it. Of course, the PR [1] can't be merged, as it will introduce a dependency cycle, so I'm -1'ing that PR too, given the blocker it will introduce to the Apache KIE 10 release. Is this image being used anywhere else? Or is `kn-plugin-workflow` the only place using it? Why does it need to stay at `kogito-images` and can't go to `kie-tools`? Same questions for the image being introduced by [1]. Let me know if I'm missing something, but I feel like our best course of action now would be moving the images to `kie-tools`. Regards, Tiago Bento [1] https://github.com/orgs/apache/repositories?language=&q=incubator-kie&sort=&type=all On Wed, Mar 6, 2024 at 9:59 AM Alex Porcelli <[email protected]> wrote: > > Ricardo, > > Here's a better description [1] of the dependency that KIE Tools has > with the images. If we have kogito images moved to after KIE Tools, I > think we'd create a new circular dependency. > > [1] - > https://github.com/apache/incubator-kie-issues/issues/821#issuecomment-1896206199 > > On Wed, Mar 6, 2024 at 9:43 AM ricardo zanini fernandes > <[email protected]> wrote: > > > > Alex, > > > > I'm not aware of any dependencies in KIE Tools for images. > > > > On Wed, Mar 6, 2024 at 9:44 AM Alex Porcelli <[email protected]> wrote: > > > > > Ricardo, > > > > > > IIRC, there’s a dependency in KIE Tools for serverless workflow with > > > images… if this is correct, your proposal will introduce a new circular > > > dependency. > > > > > > > > > On Wed, Mar 6, 2024 at 7:39 AM ricardo zanini fernandes < > > > [email protected]> wrote: > > > > > > > Hi! > > > > > > > > A strong -1 from my side moving the images to kie-tools. We can release > > > the > > > > images after a kie-tools release or patch the images with a new > > > > kie-tools > > > > release if that comes out. It's ok to depend on it, I just need help to > > > > setup the pipelines and CI. > > > > > > > > So, when releasing SonatFlow images, we can grab the latest available > > > > kie-tools version, pack it and ship it. If a new release comes up and we > > > > need the fix, we can of course do a patch release. > > > > > > > > We just need to automate the process. > > > > > > > > Cheers! > > > > > > > > On Wed, Mar 6, 2024 at 9:33 AM Alex Porcelli <[email protected]> > > > wrote: > > > > > > > > > Dominik, > > > > > > > > > > The plans and course of action for removing the circular dependency > > > > > has > > > > > been exhaustively discussed in the mailing list and Zulip channel > > > > > among > > > > > community and key stakeholders, I don’t think we have room to revisit > > > the > > > > > decision that has been already agreed. > > > > > > > > > > With that being said, I don’t think the current plans removes any > > > > > functionality, we are just moving things from one repository to > > > another. > > > > > > > > > > > > > > > On Wed, Mar 6, 2024 at 2:19 AM Dominik Hanak <[email protected]> > > > > > wrote: > > > > > > > > > > > Hi Tiago, > > > > > > > > > > > > that is a problem, we are removing an important functionality for > > > > > > our > > > > SWF > > > > > > users, imho it is a killer feature in this case. > > > > > > I am against it, there needs to be a solution where we can depend on > > > > > > kie-tools with kie-kogito-images. > > > > > > > > > > > > Another thing that is currently open as a PR [2] that makes images > > > > depend > > > > > > on kie-tools. Here we are following > > > > > > the approach you started in kiegroup and we were not aware of any > > > > > changes, > > > > > > now with the unexpected and sudden changes it is irrelevant? > > > > > > Do you have a proposal on how to achieve what we have in [2] after > > > the > > > > > > circular dependency issue is fixed according to the proposal > > > > annoucement? > > > > > > > > > > > > Dominik > > > > > > > > > > > > > > > > > > [2] https://github.com/apache/incubator-kie-kogito-images/pull/1734 > > > > > > > > > > > > > > > > > > On Wed, 6 Mar 2024 at 02:10, Tiago Bento < > > > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > Hi Dominik, > > > > > > > > > > > > > > That is indeed an oversight on our part. Thanks for pointing that > > > > out. > > > > > > > > > > > > > > Unfortunately, given the two development streams (`drools` and > > > > > > > `kogito-*`, and `kie-tools`), we can't have `kogito-images` > > > depending > > > > > > > on packages that will start being hosted on `kie-tools`, since > > > > > > > `kogito-images` is part of the `drools` and `kogito-*` development > > > > > > > stream, which is upstream from `kie-tools`' perspective. > > > > > > > > > > > > > > Since all Dev UI packages are moving to `kie-tools`, images on > > > > > > > `kogito-images` can't depend on them. > > > > > > > > > > > > > > I'm not familiar with the structure of `kogito-images`, nor the > > > > > > > purpose of this image that uses SWF's Quarkus Dev UI, but > > > > > > > following > > > > > > > the same reasoning we did for `kogito-management-console` and > > > > > > > `kogito-task-console`, my suggestion would be moving this image to > > > > > > > `kie-tools`. Another option I can see is simply removing the > > > Quarkus > > > > > > > Dev UI dependency on this image. > > > > > > > > > > > > > > I'd wait for other opinions, though, as I'm not the best person to > > > > > > > answer SWF-related questions. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Tiago Bento > > > > > > > > > > > > > > > > > > > > > On Tue, Mar 5, 2024 at 9:31 AM Dominik Hanak < > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Tiago, > > > > > > > > > > > > > > > > Thanks for moving this forward. > > > > > > > > > > > > > > > > I have one thing to highlight with > > > > > > > > https://github.com/apache/incubator-kie-kogito-images > > > > > > > > I noticed [1], where the swf devui is being used in an image. > > > Imho > > > > > that > > > > > > > > would require adjustments to the nightly pipelines & release > > > > process. > > > > > > > > Would it be possible to add tasks to the plan that ensure > > > required > > > > > > > > adjustments to our CI once the migration is done? > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > Dominik > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-kie-kogito-images/blob/ce62b9d86c2ea0385ab85c3ef5339afe5ecdea72/modules/kogito-swf/devmode/build-config/module.yaml#L30 > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 1 Mar 2024 at 05:54, Tiago Bento <[email protected]> > > > > > > wrote: > > > > > > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > > > > > > > Following up on the status of this effort. > > > > > > > > > > > > > > > > > > I know I'm a bit late on the email, but it paid off, as we > > > > > > > > > just > > > > had > > > > > > > > > our first green build [1] of KIE Tools with Java 17, Quarkus > > > > 3.2.9, > > > > > > > > > Maven 3.9.6 and Kogito 999-20240218-SNAPSHOT. We ended up > > > > deciding > > > > > to > > > > > > > > > do items 1. and 2. together after all, but we couldn't use the > > > > > latest > > > > > > > > > timestamped SNAPSHOT due to > > > > > > > > > https://issues.apache.org/jira/browse/INFRA-25546, which > > > > prevented > > > > > > the > > > > > > > > > publication of the timestamped SNAPSHOT to succeed. That's why > > > we > > > > > > > > > picked 20240218, not 20240225. > > > > > > > > > > > > > > > > > > We will proceed with some manual checks now to confirm that > > > > > > everything > > > > > > > > > is working properly, and I hope on the next status update we > > > will > > > > > > have > > > > > > > > > the big blocker removed and that we have already made some > > > > progress > > > > > > on > > > > > > > > > items other than 1. and 2.. > > > > > > > > > > > > > > > > > > It's been great seeing everyone working together to move this > > > > > forward > > > > > > > > > as fast as possible. Thanks a lot Eder, Thiago, Rodrigo, Alex, > > > > > > > > > Fabrizio, Paulo, and Yeser! > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-kie-tools/actions/runs/8105498131/job/22153897965 > > > > > > > > > > > > > > > > > > On Mon, Feb 26, 2024 at 5:59 AM Francisco Javier Tirado Sarti > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > Hi Tiago, > > > > > > > > > > It was a nice morning reading ;) Thanks for all the time > > > > invested > > > > > > on > > > > > > > such > > > > > > > > > > detailed writing. > > > > > > > > > > @Ricardo Zanini <[email protected]> @Walter Medvedeo > > > > > > > > > > <[email protected]> I guess dev ui can be removed > > > > from > > > > > > > current > > > > > > > > > > examples, at least from the ones I'm familiar with, since > > > their > > > > > > > README > > > > > > > > > > files do not really require any graphical tool. But to be > > > > honest, > > > > > > > since I > > > > > > > > > > have focused my work on SWF simple showcase examples, I'm > > > not > > > > > 100% > > > > > > > sure > > > > > > > > > > that's the same case for more elaborate ones, can you please > > > > > check > > > > > > > that > > > > > > > > > it > > > > > > > > > > is fine to remove dev ui? If this is not the case, maybe > > > those > > > > > > > examples > > > > > > > > > can > > > > > > > > > > be moved to the tools repository (points 9 and 10 of Tiago's > > > > > email) > > > > > > > > > > Thanks in advance. > > > > > > > > > > > > > > > > > > > > On Fri, Feb 23, 2024 at 2:29 AM Tiago Bento < > > > > > [email protected] > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > DISCLAIMER: this is a long email. Feel free to jump to the > > > > > bottom > > > > > > > for > > > > > > > > > > > the concrete task list. > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > This email aims to explain the issue and lay out the > > > efforts > > > > > that > > > > > > > are > > > > > > > > > > > in place to fix it. > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > Before we start digging into the problem, we need to > > > > > understand a > > > > > > > > > > > little bit of the history of the KIE community and the > > > Kogito > > > > > > > > > > > initiative, at least from the part I started contributing > > > to > > > > it > > > > > > > anyway > > > > > > > > > > > :) > > > > > > > > > > > > > > > > > > > > > > Back in Business Central days, we had a single stream of > > > > > > > development. > > > > > > > > > > > We had robust CI jobs that would build the entire stack, > > > from > > > > > > > `drools` > > > > > > > > > > > to `kie-wb-distributions`. When Kogito came about, there > > > was > > > > a > > > > > > > fission > > > > > > > > > > > in our pipelines. Kogito started to release independently > > > > from > > > > > > > > > > > everything else, and because of the organic way things > > > > started > > > > > to > > > > > > > > > > > organize themselves, the Kogito Tooling initiative needed > > > to > > > > > have > > > > > > > its > > > > > > > > > > > own release cycle as well. > > > > > > > > > > > > > > > > > > > > > > Up until we started the migration to Apache, Business > > > Central > > > > > > > > > > > continued on its `7.x` stream, Kogito was at `1.x` stream, > > > > and > > > > > > > Kogito > > > > > > > > > > > Tooling (which was already called KIE Tools) was still on > > > > > `0.x`. > > > > > > > > > > > Drools started its own release stream as well, with `8.x`, > > > > and > > > > > > > > > > > OptaPlanner I believe had jumped to `9.x` already. This > > > > > > > fragmentation > > > > > > > > > > > had technical implications, which we are trying to > > > > > > > > > > > overcome > > > > > right > > > > > > > now > > > > > > > > > > > with Apache KIE 10. > > > > > > > > > > > > > > > > > > > > > > The Apache KIE 10 release is aimed to be an atomic > > > > > > > > > > > release, > > > > > where > > > > > > > the > > > > > > > > > > > entire Apache KIE community follows a single release > > > stream. > > > > > This > > > > > > > > > > > means we need to make sure our code base is in sync, from > > > > > > `drools` > > > > > > > to > > > > > > > > > > > `kie-tools`. > > > > > > > > > > > > > > > > > > > > > > This whole conversation of course doesn't come without a > > > > > > > background of > > > > > > > > > > > CI pipelines, organizational perspectives of what Apache > > > KIE > > > > > is, > > > > > > > and > > > > > > > > > > > even poly- vs. mono-repo discussions. This is not the > > > > > > > > > > > focus > > > > of > > > > > > this > > > > > > > > > > > issue, and I believe with time we'll converge into > > > something > > > > > > > everyone > > > > > > > > > > > is comfortable with and that ultimately serves our users > > > > well. > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > Due to the lack of unification and flexibility while > > > > > > bootstrapping > > > > > > > new > > > > > > > > > > > efforts, KIE Tools had to come up with a way to depend on > > > the > > > > > new > > > > > > > > > > > stuff (i.e. Kogito) without sacrificing its own integrity > > > and > > > > > > > > > > > stability. KIE Tools, as many of you know, evolved to be a > > > > > > polyglot > > > > > > > > > > > monorepo, hosting Java, JavaScript/TypeScript, Go and > > > Docker > > > > > > > images. > > > > > > > > > > > There's a multitude of technologies at play on KIE Tools, > > > > which > > > > > > > > > > > ultimately gives our users KIE Sandbox, VS Code and Chrome > > > > > > > Extensions, > > > > > > > > > > > and Standalone Editors that can be used as regular > > > libraries > > > > on > > > > > > web > > > > > > > > > > > applications. > > > > > > > > > > > > > > > > > > > > > > The technical solution we found on `kie-tools` was > > > depending > > > > on > > > > > > > Kogito > > > > > > > > > > > as if it were a 3rd party dependency. We have a single, > > > fixed > > > > > > > version > > > > > > > > > > > of it and we manually upgrade it to the latest one > > > available > > > > > when > > > > > > > we > > > > > > > > > > > need to. This has worked amazingly well, allowing us to > > > > > > > > > > > own > > > > the > > > > > > > > > > > codebase and avoid random breaks coming from SNAPSHOT > > > > > artifacts. > > > > > > > > > > > > > > > > > > > > > > This allowed the `drools` and `kogito-*` repositories to > > > > evolve > > > > > > > > > > > independently of `kie-tools`. This also made `kie-tools` > > > > > > > responsible > > > > > > > > > > > for adapting itself to changes coming from `drools` and > > > > > > `kogito-*`. > > > > > > > > > > > Luckily, we didn't have many incompatibilities, but right > > > now > > > > > we > > > > > > > have > > > > > > > > > > > an important one, that we'll discuss below. > > > > > > > > > > > > > > > > > > > > > > Note that at this point, and for this issue in particular, > > > it > > > > > is > > > > > > > > > > > unimportant to discuss why things were done the way they > > > > were, > > > > > or > > > > > > > what > > > > > > > > > > > we should've done instead. I'm laying out the facts so > > > > > > > > > > > that > > > > we > > > > > > can > > > > > > > > > > > understand how we're moving forward now. Of course, I > > > > > > > > > > > would > > > > > > > personally > > > > > > > > > > > love to debate this on a separate thread :) > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > One of the most impactful features of KIE Sandbox is the > > > DMN > > > > > > > Runner. > > > > > > > > > > > It allows people to rapidly interact with their Decisions > > > as > > > > > they > > > > > > > > > > > author them, and this was all made possible because of the > > > > JIT > > > > > > > > > > > Executor (hosted at `kogito-apps`). KIE Sandbox also > > > started > > > > to > > > > > > > allow > > > > > > > > > > > users to deploy their Decisions to OpenShift, then later > > > > > > > > > > > to > > > > > > > > > > > Kubernetes, and now recently we allow users to deploy > > > > anything > > > > > to > > > > > > > > > > > OpenShift and Kubernetes, with a very high level of > > > > > > customization. > > > > > > > All > > > > > > > > > > > these features depend on `kogito-*`, Quarkus, and all the > > > > > things > > > > > > > that > > > > > > > > > > > come with them. Including the Java version. > > > > > > > > > > > > > > > > > > > > > > Logically, `kie-tools` depends on `drools` and `kogito-*`, > > > as > > > > > > > `drools` > > > > > > > > > > > and `kogito-*` can (and do!) exist and function without > > > > Tools, > > > > > > but > > > > > > > not > > > > > > > > > > > the other way around. > > > > > > > > > > > > > > > > > > > > > > As `kie-tools` started growing, maturing, and releasing > > > some > > > > > > > pieces of > > > > > > > > > > > technology that were useful to other domains (i.e. > > > > Multiplying > > > > > > > > > > > Architecture), it became a dependency for other projects. > > > > Users > > > > > > > > > > > started depending on our Standalone Editors, but also on > > > the > > > > > > > > > > > Multiplying Architecture packages. One good example is > > > Kaoto, > > > > > > which > > > > > > > > > > > released a VS Code extension aligned with our > > > > > > > > > > > architecture. > > > > > > > > > > > > > > > > > > > > > > The capability of encapsulating web components in any > > > > > technology > > > > > > > > > > > behind a well defined, statically typed API was really > > > > > appealing, > > > > > > > and > > > > > > > > > > > when the Kogito initiative started to design their Runtime > > > > > Tools > > > > > > > > > > > (i.e., Quarkus Dev UIs, Management Console, and Task > > > Inbox), > > > > > > using > > > > > > > the > > > > > > > > > > > Multiplying Architecture was the way to go. > > > > > > > > > > > > > > > > > > > > > > That's when the circular dependency started. We had > > > > > > > > > > > `kogito-apps/ui-packages` depending on `kie-tools`. Note > > > that > > > > > it > > > > > > > was > > > > > > > > > > > also logical for these packages to be part of the > > > `kogito-*` > > > > > > > > > > > repositories and release stream. Users upgrading to a new > > > > > version > > > > > > > of > > > > > > > > > > > Kogito would also need to have their Task Inbox, > > > > > > > > > > > Management > > > > > > > Console, > > > > > > > > > > > and Quarkus Dev UIs aligned with the new version of > > > > > > > > > > > Kogito. > > > > Not > > > > > > to > > > > > > > > > > > mention Job Service, Data Index etc. > > > > > > > > > > > > > > > > > > > > > > For many months (or years!), this was not an issue, as the > > > > > > > Multiplying > > > > > > > > > > > Architecture packages were very stable and very rarely > > > > > > > > > > > were > > > > > > > modified. > > > > > > > > > > > The last big change we had was 3 years ago, with the > > > > > introduction > > > > > > > of > > > > > > > > > > > Shared Values [1], which did not impact the > > > > > > > > > > > fire-and-forget > > > > and > > > > > > > > > > > Promise-based mechanisms we already had in place. > > > > > > > > > > > > > > > > > > > > > > Although we were aware of this circular dependency from > > > > > > > > > > > the > > > > > > > beginning, > > > > > > > > > > > it was not that big of a deal for `kogito-apps` to depend > > > on > > > > an > > > > > > > older, > > > > > > > > > > > dephased version of `kie-tools`. We didn't have plans of > > > > > unifying > > > > > > > the > > > > > > > > > > > streams anyway, and it was the best solution for our users > > > to > > > > > > have > > > > > > > > > > > their Runtime Tools packages released together with the > > > > Kogito > > > > > > > stream. > > > > > > > > > > > > > > > > > > > > > > That of course changed after the migration to Apache. > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > If you reached this point, thank you for your interest in > > > > > > > > > > > a > > > > > > little > > > > > > > bit > > > > > > > > > > > of the history of KIE, and I hope you can now understand > > > why > > > > > > things > > > > > > > > > > > are the way they are. Let's talk about what changed and > > > what > > > > we > > > > > > are > > > > > > > > > > > doing to adapt to the new requirements. > > > > > > > > > > > > > > > > > > > > > > Hinting a little bit to what I mentioned above, this > > > > discussion > > > > > > is > > > > > > > > > > > very intertwined with the CI pipelines and > > > > versioning/releasing > > > > > > > > > > > strategies subjects, as we are essentially discussing code > > > > > > > > > > > organization, coupling/decoupling and granularity of > > > > > > > > > > > stuff, > > > > and > > > > > > to > > > > > > > > > > > make things easier at least for a while, `drools` and > > > > > `kogito-*` > > > > > > > will > > > > > > > > > > > continue being a separate stream from `kie-tools`. > > > > > > > > > > > > > > > > > > > > > > `drools` and `kogito-*` will continue being able to evolve > > > > > > > > > > > independently of `kie-tools`, and `kie-tools` will > > > > > > > > > > > continue > > > > > > > adapting > > > > > > > > > > > itself to whatever changes on `drools` and `kogito-*`. > > > > > > > > > > > > > > > > > > > > > > At the same time, Apache KIE 10 (and the next releases > > > too!) > > > > > will > > > > > > > be > > > > > > > > > > > atomic. And for our users, a single release stream. > > > > `drools@10 > > > > > ` > > > > > > > and > > > > > > > > > > > `kogito-*@10` will be used on `kie-tools@10`. We started > > > > this > > > > > > > effort a > > > > > > > > > > > while ago, and although we should've been more open about > > > it > > > > > from > > > > > > > the > > > > > > > > > > > beginning, we are also learning how to properly > > > > > > > > > > > communicate > > > > > > inside > > > > > > > the > > > > > > > > > > > Apache structure. Better late than never :) Thanks for the > > > > tip > > > > > > > Tibor! > > > > > > > > > > > > > > > > > > > > > > Here's how we'll do it: > > > > > > > > > > > > > > > > > > > > > > 1. A couple of weeks ago, one of our newest committers. > > > > Rodrigo > > > > > > > > > > > Antunes, created automated jobs to weekly publish a > > > > timestamped > > > > > > > > > > > SNAPSHOT version of `drools` and `kogito-*`. This will > > > allow > > > > us > > > > > > to > > > > > > > > > > > have a persistent, immutable version to point to on > > > > > `kie-tools`, > > > > > > > even > > > > > > > > > > > without having a full release. Timestamped SNAPSHOTs, as > > > > we're > > > > > > > calling > > > > > > > > > > > them, are a little bit different than normal Maven > > > SNAPSHOTs, > > > > > as > > > > > > > there > > > > > > > > > > > is no `updatePolicy`, so as time passes, the downloaded > > > > > artifacts > > > > > > > do > > > > > > > > > > > not change. This allows `kie-tools` to be stable and > > > > > incorporate > > > > > > > > > > > changes done to `drools` and `kogito-*` at its own pace. > > > > > > > > > > > We > > > > > also > > > > > > > moved > > > > > > > > > > > the publication of `@kie-tools/jitexecutor-native` to this > > > > new > > > > > > > job, so > > > > > > > > > > > we won't have to maintain it on the `kie-tools` side > > > anymore. > > > > > > > Thanks > > > > > > > > > > > Rodrigo! > > > > > > > > > > > > > > > > > > > > > > 2. When we define the code freeze prior to releasing > > > > > > > > > > > Apache > > > > > KIE, > > > > > > > > > > > `drools` and `kogito-*` will need to be frozen a little > > > > > > > > > > > bit > > > > > > earlier > > > > > > > > > > > than `kie-tools`, leaving a buffer for `kie-tools` to > > > > > > > > > > > start > > > > > > > pointing > > > > > > > > > > > to the latest timestamped SNAPSHOT and adapting itself to > > > the > > > > > > > changes. > > > > > > > > > > > My initial thoughts are around 2 weeks, but with constant > > > > > updates > > > > > > > and > > > > > > > > > > > proper alignment between the two streams, I see this time > > > > > > reducing > > > > > > > to > > > > > > > > > > > a couple of days for upcoming releases. > > > > > > > > > > > > > > > > > > > > > > 3. After `kie-tools` is fully functional pointing to the > > > > latest > > > > > > > > > > > timestamped SNAPSHOT of `drools` and `kogito-*`, we can > > > > > > > > > > > now > > > > > start > > > > > > > > > > > preparing for the actual release. We will cut new branches > > > > for > > > > > > the > > > > > > > > > > > next version (i.e. 10.0.0) and update all configuration > > > files > > > > > > that > > > > > > > we > > > > > > > > > > > have to. This will be done on `drools`, `kogito-*`, and > > > > > > > `kie-tools`. > > > > > > > > > > > Every module/package will declare the same version, and > > > will > > > > > > > depend on > > > > > > > > > > > the upstream modules/packages with the same version as > > > well. > > > > We > > > > > > can > > > > > > > > > > > proceed with this staging phase as normal. Running > > > > > > automated/manual > > > > > > > > > > > tests and eventually signing off that everything is good > > > > > > > > > > > to > > > > go. > > > > > > > (I'm > > > > > > > > > > > not 100% on the timeline for the Apache release, but with > > > > this > > > > > > > process > > > > > > > > > > > we can guarantee that we will vote on branches that won't > > > > > change > > > > > > > when > > > > > > > > > > > we decide to release. It will be a matter of pushing tags > > > > > > pointing > > > > > > > to > > > > > > > > > > > these release branches). > > > > > > > > > > > > > > > > > > > > > > With the release process defined, we can now discuss the > > > > exact > > > > > > > actions > > > > > > > > > > > we're taking to remove the circular dependency we have > > > > between > > > > > > > > > > > `kie-tools` and `kogito-apps`. All of which will need to > > > > > > > > > > > be > > > > > > > addressed > > > > > > > > > > > prior to starting the release process. > > > > > > > > > > > > > > > > > > > > > > 1. (Fabrizio - IN PROGRESS) Make sure `kie-tools` is on > > > Java > > > > > 17, > > > > > > > Maven > > > > > > > > > > > 3.9.6, and Quarkus 3. > > > > > > > > > > > (https://github.com/apache/incubator-kie-issues/issues/960 > > > ) > > > > > > > > > > > There's a complication here, since we still have three > > > > big > > > > > > > > > > > packages (Serverless Workflow Diagram Editor, BPMN, DMN, > > > and > > > > > > SceSim > > > > > > > > > > > Editors, and DashBuilder) on `kie-tools` that need GWT, > > > > > > > > > > > and > > > > as > > > > > > you > > > > > > > > > > > know, GWT together with Java upgrades usually require some > > > > > work. > > > > > > > We're > > > > > > > > > > > on GWT 2.10, which should already support Java 17, but > > > we'll > > > > > know > > > > > > > more > > > > > > > > > > > once we try it. > > > > > > > > > > > > > > > > > > > > > > 2. (Fabrizio - NOT YET STARTED) Make sure `kie-tools` is > > > > using > > > > > > the > > > > > > > > > > > latest timestamped SNAPSHOT from `kogito-*`. > > > > > > > > > > > (https://github.com/apache/incubator-kie-issues/issues/965 > > > ) > > > > > > > > > > > We have them built and published every Sunday EOD, so > > > on > > > > > > Monday > > > > > > > > > > > (Feb 25th, 2024) we'll have a brand new one to start > > > working > > > > > > with. > > > > > > > > > > > > > > > > > > > > > > 3. (Thiago - IN PROGRESS) Move `kogito-apps/ui-packages` > > > > > > > > > > > to > > > > > > > > > > > `kie-tools`. ( > > > > > > > > > https://github.com/apache/incubator-kie-issues/issues/833) > > > > > > > > > > > We started a couple of weeks ago, and we should be > > > > > > > > > > > ~80% > > > > > done > > > > > > > with > > > > > > > > > it > > > > > > > > > > > by now. > > > > > > > > > > > > > > > > > > > > > > 4. (Fabrizio - PR SENT, but blocked by 1. and 2.) Move the > > > > SWF > > > > > > > Quarkus > > > > > > > > > > > Dev UI package from `kogito-apps` to `kie-tools`. > > > > > > > > > > > (https://github.com/apache/incubator-kie-tools/pull/2167) > > > > > > > > > > > This can only be done after 1. and 2. are merged, > > > > > > > > > > > since > > > > > this > > > > > > > move > > > > > > > > > > > will require `kie-tools` to be ready to build packages > > > > > > > > > > > with > > > > > Java > > > > > > > 17, > > > > > > > > > > > Maven 3.9.6, and Quarkus 3. > > > > > > > > > > > > > > > > > > > > > > 5. (Thiago - NOT YET STARTED) Move the BPMN Quarkus Dev UI > > > > > > package > > > > > > > > > > > from `kogito-apps` to `kie-tools`. > > > > > > > > > > > (https://github.com/apache/incubator-kie-issues/issues/966 > > > ) > > > > > > > > > > > We'll follow the lead of Fabrizio's PR from 4. That's > > > > > > > essentially > > > > > > > > > > > doing exactly the same thing for the BPMN Quarkus Dev UI > > > > > module. > > > > > > > > > > > > > > > > > > > > > > 6. (Rodrigo - NOT YET STARTED) Change the Jenkins release > > > > jobs > > > > > to > > > > > > > > > > > include publishing both Quarkus Dev UI modules to Maven > > > > central > > > > > > as > > > > > > > > > > > part of the Apache release. > > > > > > > > > > > (https://github.com/apache/incubator-kie-issues/issues/964 > > > ) > > > > > > > > > > > Should be pretty straight-forward, as we already have > > > > > > > experience > > > > > > > > > > > doing this for other repos. > > > > > > > > > > > > > > > > > > > > > > 7. (Thiago - NOT YET STARTED) Change the ownership of > > > > > > > `task-console` > > > > > > > > > > > and `management-console` images from `kogito-images` to > > > > > > > `kie-tools`. > > > > > > > > > > > (https://github.com/apache/incubator-kie-issues/issues/963 > > > ) > > > > > > > > > > > KIE Tools already hosts and publishes several images, > > > and > > > > > > since > > > > > > > > > > > the content of those images will now be hosted at > > > > `kie-tools`, > > > > > we > > > > > > > can > > > > > > > > > > > only host them there. > > > > > > > > > > > This also means we'll get rid of the two Quarkus apps > > > [2] > > > > > > that > > > > > > > > > > > wrap both consoles' static assets. We could be wrong about > > > > the > > > > > > > purpose > > > > > > > > > > > of those apps, so if anyone has more information, please > > > > > > > > > > > do > > > > > reach > > > > > > > out. > > > > > > > > > > > Otherwise, we'll skip the Quarkusification of those static > > > > > assets > > > > > > > and > > > > > > > > > > > we'll ship images with `httpd` directly, like we do for > > > > > > > > > > > KIE > > > > > > > Sandbox. > > > > > > > > > > > > > > > > > > > > > > 8. (Assignee TDB - NOT YET STARTED) Deleting everything > > > that > > > > > was > > > > > > > moved > > > > > > > > > > > to `kie-tools` from `kogito-apps`. > > > > > > > > > > > (https://github.com/apache/incubator-kie-issues/issues/962 > > > ) > > > > > > > > > > > That will be the point where we actually get rid of > > > > > > > > > > > the > > > > > > > circular > > > > > > > > > > > dependency and remove the blocker for the release. > > > > > > > > > > > > > > > > > > > > > > 9. (Assignee TDB - NOT YET STARTED) Adapt > > > > > > > > > > > `kogito-examples` > > > > to > > > > > > all > > > > > > > the > > > > > > > > > > > changes we mentioned above. > > > > > > > > > > > (https://github.com/apache/incubator-kie-issues/issues/961 > > > ) > > > > > > > > > > > Kogito Examples keeps being part of the `drools` and > > > > > > `kogito-*` > > > > > > > > > > > stream, meaning that example modules won't be able to use > > > > > neither > > > > > > > of > > > > > > > > > > > the Quarkus Dev UIs, as `kie-tools` is downstream in > > > relation > > > > > to > > > > > > > the > > > > > > > > > > > `drools` and `kogito-*` stream. > > > > > > > > > > > The same would be true for Management Console and Task > > > > > > Console > > > > > > > > > > > images, but for them, we can use the `daily-dev` tag we > > > > publish > > > > > > > daily > > > > > > > > > > > from `kie-tools@main`. > > > > > > > > > > > > > > > > > > > > > > 10. (Assignee TDB - NOT YET STARTED) Create some example > > > apps > > > > > > that > > > > > > > use > > > > > > > > > > > the Quarkus Dev UIs directly on the `examples` directory > > > > > > > > > > > of > > > > > > > > > > > `kie-tools`. ( > > > > > > > > > https://github.com/apache/incubator-kie-issues/issues/959) > > > > > > > > > > > This is to serve the same purpose of packages that did > > > > that > > > > > > on > > > > > > > > > > > `kogito-examples`, but now hosted on `kie-tools`. > > > > > > > > > > > > > > > > > > > > > > Pheew! That's a lot of things to do, but it is the result > > > of > > > > > two > > > > > > > > > > > intense weeks assessing and planning how we would address > > > > this > > > > > > > issue > > > > > > > > > > > in a way that the Apache KIE 10 release can be done in a > > > way > > > > > that > > > > > > > > > > > feels atomic to our users, who are ultimately the most > > > > > important > > > > > > > part > > > > > > > > > > > of the community. There's an open EPIC too at > > > > > > > > > > > https://github.com/apache/incubator-kie-issues/issues/967. > > > > > > > > > > > > > > > > > > > > > > I appreciate it if you reached this point, and hope you > > > feel > > > > > > > welcome > > > > > > > > > > > to contributing to solving this lengthy and historical > > > > problem > > > > > if > > > > > > > you > > > > > > > > > > > feel like doing so. > > > > > > > > > > > > > > > > > > > > > > I'll personally send updates to this thread every week, on > > > > > > Thursday > > > > > > > > > > > nights. Do not hesitate to contact me or any of the people > > > > > > > involved in > > > > > > > > > > > this effort if you have questions, or simply want to chat > > > > about > > > > > > it. > > > > > > > > > > > > > > > > > > > > > > Thanks a lot Alex, Paulo, Fabrizio, Thiago, Rodrigo, and > > > > others > > > > > > > that > > > > > > > > > > > somehow helped so far. > > > > > > > > > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > > > > > > > > > > > Tiago Bento > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > P.S.: You might've noticed we left Trusty out of the > > > picture > > > > > for > > > > > > > now. > > > > > > > > > > > Thiago is conducting an investigation to understand what > > > > would > > > > > be > > > > > > > the > > > > > > > > > > > best course of action for it. As much as we have plans to > > > > > revive > > > > > > > it, > > > > > > > > > > > right now our focus has to be on getting Apache KIE 10 > > > > > > > > > > > out. > > > > We > > > > > > can > > > > > > > > > > > always rely on Git to bring it back in the future, if we > > > > > > ultimately > > > > > > > > > > > decide that wiping out Trusty is the best strategy for > > > > > > > > > > > this > > > > > > moment. > > > > > > > > > > > > > > > > > > > > > > [1] https://github.com/apache/incubator-kie-tools/pull/691 > > > > > > > > > > > > > > > > > > > > > > [2] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-kie-kogito-apps/tree/main/task-console > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-kie-kogito-apps/tree/main/management-console > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
