Hello Neil, Hello developers, *TL;DR;* Any Apache Netbeans developer with write access to the Friends-of-Apache NetBeans installers' repositories can update and deploy NetBeans installer packages on https://installer.friendsofapachenetbeans.org. Details about this simple process are at the end.
*Background information.* This document describes only the installers/packages provided by Friends of Apache NetBeans (FoAN). The Apache NetBeans binary releases provided by the Apache NetBeans developers under the guidance of the Programme Management Committee (PMC) are an excellent way to distribute the IDE as an installable program bundle. However, there is a group of potential end users who prefer a package or installer that feels more natural to their platform. Examples include a Windows installer in executable (exe) form for Microsoft Windows users; pkg installers for macOS and Debian (deb) packages; and RPM packages for Linux users. The essential *extra* in these installers/packages is the inclusion of a Java runtime so the IDE runs out of the box. Since a Java Runtime is OS- and architecture-specific, this results in the 6 installers: 1. exe installer for Microsoft Windows x86, 2. pkg for Apple macOS, arm64 (Apple Silicon), 3. pkg for Apple macOS, 4. deb for x86 (Debian, Ubuntu etc) 5. deb for arm64 (think Raspberry Pi) and 6. rpm (Red Hat Linux, Oracle Linux, Fedora, SuSE, etc) for x86. In all cases above, the JDK must be freely redistributable. This has to take place outside the Apache organisation because it does not allow bundling Apache-licensed software with non-Apache-licensed software within the organisation. Currently, there exists no JDK or JRE with an Apache license. All these installers are created automatically using a combination of Apache NetBeans nbpackage <https://github.com/apache/netbeans-nbpackage> and some scripting, and run as GitHub Actions. For Windows and Apple macOS, there is an additional platform requirement that the executable or package be *signed* or *signed and notarised*, which involves certificates and a certain level of security and trust. Apple effectively provides only one path: sign with an Apple-provided certificate and notarization service, the later run by Apple in I believe the Amazon clouds. This costs USD 99, unless you can obtain a free waiver. In both cases, my experience is that the higher cost is having patience. Apple's mills run slowly in this regard. For Windows signing, there are more possible paths, as long as the signing is done with a valid certificate. The signing can either be done on your local developer machine using a trusted hardware device, or in a GitHub action with either a secure certificate storage in the Azul secure vault cloud service, or by using a trusted party that takes care of the secure handling of the certificate. The last two paths are used in the two variants that are currently available: Codelerity uses the Azul secure vault path; FoAN chose to use the services of SignPath to obtain and securely handle the signing of the Windows installer exe file. The costs for a code-signing certificate are higher than those of an Apple license. Typically a few hundred dollars. There are multiple JDKs to choose from. Codelery prefers the Temurin variant; FoAN chooses the Azul variant, for various reasons. Others might be considered. >From the above, it follows that having signed installers/packages creates involvement with other parties, at least with Apple and/or a Certificate Authority. If a developer already has such involvement than all the work is in updating the secrets that are used in the current GitHub workflows. If not, and a developer wants to develop other variants or combinations or even bundle his own NetBeans platform Rich Client application, and we want to provide this as an example repository, then we may need to break up the build workflow into separate package and sign steps, so the signing (and notarisation) steps are optional. This could be done by introducing intermediate steps or by using checkboxes to enable signing (Windows) or signing and notarization (macOS). *Steps to take to create and deploy a FoAN installer.* You need write access to the installers <https://github.com/Friends-of-Apache-NetBeans/netbeans-installers> and installers-site <https://github.com/Friends-of-Apache-NetBeans/netbeans-installers-site> repositories. At the time of writing: - Visit the installers repo, releases page. - Create a *draft* release, based on an existing tag. E.g. V29-build1 for both tag and git release name - In actions choose the *build* action, - Click the run workflow button and - select which installers to build and provide the release name given earlier. - Click the Run workflow button. This triggers the build for selected installers. The builds should complete in about 10 minutes for all. [image: image.png] - After some time (typically 45 minutes) ,select the Staple action, which is only needed if your selection includes one or both macOS packages. - [image: image.png] - Go to the releases page and inspect the result. Potentially update the release notes. When you are ready to publish, turn the draft release into a public release, so that it is visible to the world. (Optional). The next steps are also optional. - To deploy the releases to the installers website <https://installers.friendsofapachenetbeans.org>, go to the site update action <https://github.com/Friends-of-Apache-NetBeans/netbeans-installers-site/actions/workflows/update.yaml> and run it with the release nae used earlier. - After completion, select the deploy action <https://github.com/Friends-of-Apache-NetBeans/netbeans-installers-site/actions/workflows/update.yaml>, which takes no parameters. - The result should be available on the installers website <https://installers.friendsofapachenetbeans.org/>. Met vriendelijke groet, Pieter van den Hombergh. Kerboschstraat 12 5913 WH Venlo
