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 >
