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
