Hi Christofer, thanks for your offer!
I cannot point you out to a specific issue, but we will soon start the new 10.2 release and if you can look at it and provide suggestions that would be great. I include the document for the release procedure here. Thanks again! PaoloB On Tue, Feb 10, 2026 at 3:37 PM Christofer Dutz <[email protected]> wrote: > Also if the release process itself is complicated/flaky, possibly > something I can help with. > I guess what brought me commit rights in most of my apache projects, is my > Maven expertise and my ability to get almost any build working ;-) > > In case you need help with that … please guide me to where you see the > biggest problems. > > Chris > > > Von: Christofer Dutz <[email protected]> > Datum: Dienstag, 10. Februar 2026 um 15:34 > An: [email protected] <[email protected]> > Betreff: AW: [DISCUSSION] Change of the binaries release model > > Hi all, > > So in PLC4X we had the „problem“ that we target multiple programming > languages and therefore need multiple toolchains for building. > In the last years I invested quite a bit of time into developing a system > based on some simple bash scripts that automate a lot of the things of a > release. > One important point is, that it generally executes the release on a > reference Docker container. With this the setup is not an issue. > > My goal with this is, that theoretically anyone in our community would be > able to do a release. > https://github.com/apache/plc4x/tree/develop/tools > Still haven’t finished the last step: release-3-finish-release.sh< > https://github.com/apache/plc4x/blob/develop/tools/release-3-finish-release.sh>, > but the first 3 should be helpful. > > Chris > > > Von: Gabriele Cardosi <[email protected]> > Datum: Dienstag, 10. Februar 2026 um 14:45 > An: [email protected] <[email protected]> > Betreff: Re: [DISCUSSION] Change of the binaries release model > > Hi Tibor, > I understand your point about reliable and steady release cycle. Anyway, > from my perspective, what slows us is not the last step of building and > releasing the binaries, but all the previous ones during which critical > modifications are implemented, thoroughfully tested and, finally, merged. > AFAIK Kennedy is following that, lately, and in another thread he shared > the current status for next release. > So, it could also be interesting his POV to understand how much the release > cycle could benefit from the removal of the binaries build. > Anyway, from what I know and understood, I've the impression that this > approach won't help us very much to improve the release cycle and would > create problems on user side. > M2C > > Best > > Gabriele > > Il Mar 10 Feb 2026, 12:25 Tibor Zimányi <[email protected]> ha scritto: > > > Hi Christofer, > > > > thank you for your input. > > > > The delays are a set of multiple things. There are some requirements from > > Apache we are working on, e.g. that targets our legacy code. Then we > have, > > from my perspective, some process problems - like not having a maintainer > > for the releases. People step up, but at the end, from the outside, it > > looks like they don't have much time to dedicate for a release. So it is > a > > mix of things. I hope we can sort this out in the near future somehow. We > > need a stable release train. That is why I opened this thread with my > > proposal. I honestly feel it would benefit us currently, however based on > > your information, it would be much harder done than I thought. > > From the contributions perspective, this community is well alive. People > > can take a look at the commits or PRs in the main repositories to see a > lot > > is happening. It is just public releases that takes longer than we would > > like. Of course people could use SNAPSHOT artifacts meanwhile, if they > need > > to use the "latest greatest", however it is not ideal. > > > > Best regards, > > Tibor > > > > On Tue, Feb 10, 2026 at 10:48 AM Christofer Dutz < > > [email protected]> > > wrote: > > > > > Hi all, > > > > > > I’d also like to point out that historically a release of an Apache > > > project usually is only the source bundle. > > > Binaries are usually considered „convenience binaries“. This is > currently > > > changing a bit, but as far as I know it’s still the standing rule that > > > Apache releases sources. > > > > > > I also would be a bit hesitant installing the binaries of a usually > > > commercial entity. Especially as that would not be allowed to use the > > > groupId (in maven terms) and also wouldn’t be allowed to call it any of > > the > > > names protected by the Apache trademarks (KIE has a wide set of names > > that > > > fall under this … and for example another vendor wouldn’t be allowed to > > > call it „com.mycorp.kie:drools“ … this would add quite a bit of > > confusion … > > > which product name by which vendor matches to which Apache KIE product > … > > > and which product name of vendor A is basically the same as that of > > vendor > > > B? > > > > > > May I ask why binaries are keeping up the releases so much? In most > > > projects I’m involved in, we treat the source-archive as what we vote > on > > > and we expect the resulting binary to be compliant (after initially > > ironing > > > out the quirks). > > > > > > Chris > > > > > > Von: Tibor Zimányi <[email protected]> > > > Datum: Dienstag, 10. Februar 2026 um 09:47 > > > An: [email protected] <[email protected]> > > > Betreff: Re: [DISCUSSION] Change of the binaries release model > > > > > > Hi, > > > > > > thanks for the replies. All are valid concerns. To clarify, I wanted to > > > highlight another possible approach we could take with the releases, > > > because we are not currently able (based on our past releases) to > release > > > in a steady stream in the community itself. So I wanted to think out of > > the > > > box, how to unblock this. The truth is, that no matter how often we > > > discussed in the past, that we need to start releasing regularly, it > > still > > > doesn't happen. So I wanted to offer another perspective, even with the > > > drawbacks of not having community binaries (with the hope that > > potentially > > > vendors would jump on it and provide their own). Currently with this > > > release cadence, I personally don't see much difference to the current > > > state. It would only get formalized. > > > > > > And if it opens the topic of releases and their cadence, only that > would > > be > > > a benefit from my perspective. > > > > > > So if we want to shift to the topic of releases themselves, and we > would > > > still want to provide the binaries, I would personally vote to find a > > > dedicated person for the releases. With the effort that was done till > > now, > > > it obviously doesn't work. I know there were blocking topics for the > > > releases, but still, this amount of time between releases, I would > > > personally consider as enough time to do them (even more regularly). > > > I personally think it is not a problem of not having a monorepo (as > some > > > people tend to bring the topic back regularly). In the past, before > > Apache, > > > we had much more repositories and we were able to release normally in a > > > normal release cadence. Now we have few and the releases take nearly a > > > year. What is the difference is that back then we had dedicated people > > for > > > the releases. I personally think that if we don't find a sort of > official > > > releases maintainer, similarly as we have maintainers taking care of > the > > > other parts of the codebase, no matter how we would try, it would > always > > > end up with these kind of delays and would circle back to my original > > > proposal from this thread. > > > > > > Best regards, > > > Tibor > > > > > > On Tue, Feb 10, 2026 at 9:22 AM Gabriele Cardosi < > > > [email protected]> > > > wrote: > > > > > > > Hi Tibor, > > > > I'm also slightly doubtful about your proposal: > > > > > > > > 1. what are the benefits, i.e. what's the goal ? AFAIK, most of our > > > delays > > > > are related to the modification and check of the sources themselves: > > > > simply avoid the delivery of the final artifacts won't be, again > IINW, > > > such > > > > a big gain > > > > 2. AFAIK, it is already possible for anyone to clone the release tag > > and > > > > make its own build, replacing all the GAVs > > > > 3. you mention the OpenJDK model as comparison, but in that context > > there > > > > was/is such a huge request for freely available implementations of > the > > > JDK > > > > that lot of providers jumped in since the acquisition of Sun from > > > > Oracle (IIRC); in our context, on the other side, I'm afraid we'll > run > > > the > > > > risk of increasing even more the difficulty to adopt our solutions > > > (someone > > > > else should take the burden of creating and delivering the binaries) > > that > > > > people will start looking around for simpler alternatives (this more > or > > > > less is the same shared by Tony) > > > > > > > > Please let me know if I misunderstood or missed something in your > > > proposal. > > > > > > > > Cheers! > > > > > > > > > > > > > > > > On Tue, Feb 10, 2026 at 9:07 AM Toni Rikkola <[email protected]> > > wrote: > > > > > > > > > Looks like releasing sources is possible. > > > > > > > > > > The #2 is what worries me. There would be no signed binaries for > the > > > > > community. > > > > > > > > > > Community is where the majority of our users are and where there is > > > > > growth potential. In the past we have mainly gotten individuals > > > > > committing code or participating. Either hobbyist or consultants. I > > see > > > > > the source release model working well for projects that have > several > > > > > vendors, each releasing a vendor signed binaries for wider audience > > > like > > > > > for a Linux distribution(s). > > > > > > > > > > Toni > > > > > > > > > > On 09/02/2026 18.01, Francisco Javier Tirado Sarti wrote: > > > > > > I think it is an interesting approach to a complex issue. That > will > > > > allow > > > > > > usage of the codebase as indirect dependency of other projects > that > > > > might > > > > > > find the current release cycle too large. > > > > > > > > > > > > On Mon, Feb 9, 2026 at 3:49 PM Tibor Zimányi < > [email protected]> > > > > > wrote: > > > > > > > > > > > >> Hi, > > > > > >> > > > > > >> as you all know, our community releases take a longer time to > get > > > out > > > > > >> currently. I would like to propose a discussion about a > different > > > > > release > > > > > >> model for our community. Here is the proposal, I am curious > about > > > your > > > > > >> feedback and what you think about it. > > > > > >> > > > > > >> 1. The community would follow a release process similar to > > OpenJDK. > > > > This > > > > > >> means, that the release would consists only from sources that > can > > be > > > > > used > > > > > >> to build the binaries and artifacts. > > > > > >> 2. No binary builds would be published as part of Apache KIE > > > > community. > > > > > >> 3. With the source code available, it would be up to vendors or > > > anyone > > > > > else > > > > > >> to decide, if they want to publish their own binaries built out > of > > > the > > > > > >> community sources. This would enable multiple various sets of > > > binaries > > > > > to > > > > > >> be available, similarly as with OpenJDK (e.g. there are Temurin > > > > builds, > > > > > IBM > > > > > >> builds, Oracle builds, etc.). > > > > > >> 4. No vendor can publish under existing Apache KIE groupIds and > > > > similar > > > > > >> artifact group names. > > > > > >> > > > > > >> This would mean, we could regularly release the source code with > > new > > > > > >> functionalities and anyone who finds it beneficial to publish a > > set > > > of > > > > > >> binaries from the sources, can do so. We may even have those > > > binaries > > > > > >> vendors published on our Apache KIE website. > > > > > >> > > > > > >> Looking forward to your feedback and discussion! I know it is a > > very > > > > > >> different to what we do now and I know that it would make it > > harder > > > > for > > > > > >> people that use the community binaries directly, however if > enough > > > > > vendors > > > > > >> of binaries jump on this, it shouldn't be a problem. > > > > > >> > > > > > >> Best regards, > > > > > >> Tibor > > > > > >> > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > -- > > > Tibor Zimanyi > > > > > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
