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] > >
