Hi Team, Following up on Stamatis's email, I want to add more context to the beeline installers' question.
- Convenient Binaries: Yes, beeline installers will be convenient binaries according to the release distribution documentation. - PGP-signing: Signing native installers is entirely possible, and to my understanding, it complies with the distribution policy. It is true, however, that it adds another step for PCM to handle, as the artifacts are signed during the release process. But it should be no different than signing the plain source code in this case. Convenient binaries could have their own .asc signature. In summary, adding beeline native installers as convenient binaries will keep the release process as it is, requiring only one additional PGP signing step. Kind regards, Illia Barbashov On Fri, Aug 21, 2026 at 12:44 PM Stamatis Zampetakis <[email protected]> wrote: > Hi Illia, > > Thanks for starting this initiative, sounds like a promising direction for > end-users! > > First of all I would encourage you to read the ASF release distribution > policy [1]. The primary ASF release artifact is source code; anything else > falls under the category of convenience binaries. The proposed native > installers also fall into the category of convenience binaries so they > should abide by the existing distribution policies [1]. If the beeline > binaries adhere to the policy then they can be put into the same > distribution channels. > > The installers are useful from a user perspective but it is certainly an > extra burden for the release cycle. On every release the PMC will have to > validate these additional binaries for compliance with the > distribution/release policy which can be tricky and time consuming. Source > validation is significantly easier than binary validation so any extra > artifact adds overhead. Personally, I would prefer to reduce the binary > release artifacts instead of increasing them so I am rather skeptical on > the addition of the beeline installers. > > In order to put artifacts in the official ASF distribution channels (SVN, > dlcdn, dockerhub, etc.) these have to pass through an official ASF vote so > they need to be approved by the PMC. Note that any artifacts that appear as > releases in GitHub are not official and we should never encourage users to > download from there and use them. > > Ideally, we should release the installers as plain source code (shell, > java, python, Dockerfiles, etc.) which users can run and produce the > necessary binaries at will in their environment. > > Best, > Stamatis > > [1] https://infra.apache.org/release-distribution.html > > On Wed, Aug 19, 2026 at 5:57 PM Illia Barbashov < > [email protected]> wrote: > >> Hi Team, >> >> We are working on creating beeline native installers: >> https://issues.apache.org/jira/browse/HIVE-29666 >> >> The upstream repository already contains the code that allows building >> the Beeline native image for Windows, Mac and Linux. Now we want to add >> this new release artifact into the current release flow. I've read the >> release guide from here: >> https://hive.apache.org/community/resources/howtorelease/#hive-release >> It seems like the Hive artifacts are copied to the SVN distro location >> and then sync-ed with https://dlcdn.apache.org/ as a part of the release >> flow. >> >> So my questions are: >> 1. Can we do the same for Beeline's native installers? >> 2. Are there any concerns or objections to this approach? >> 3. Do we need any special permissions or confirmation to do that? >> >> Kind regards, >> Illia Barbashov >> >> Software Engineer consultant at Cloudera >> >
