+1 I do agree that dropping everything outside of the two zips does look appealing. I am fairly neutral on .deb/.rpm since those are essentially repackaged variants of the zip with no extra bells and whistles (debian wiki links directly to the deb at atm since their own package is hopelessly outdated). We could keep those a bit longer maybe?
I am trying to get a few changes into the NetBeans arch packages, if accepted, makepkg would build directly from our zip source artifact. (1) A few weeks ago, I took also a quick look at winget and there it would be also theoretically possible to deploy our zip build artifact directly with some limitations. (2) Good to hear that there is work underway trying to make sure the community installers will live on in a new home! The JDK+NB bundle installer is probably the best way to get NB on windows atm anyway. I also experimented with a GraalVM native-image based launcher. It has some promising aspects, esp since the native image part is only needed on windows (only a single ~12 MB artifact). Since other systems can run the same shared java file directly from bash launch scripts, somewhat analog to the current scripts. (inspired by mvnd and launchers like mvnw and gradlew) best regards, michael (1) https://gitlab.archlinux.org/archlinux/packaging/packages/netbeans/-/merge_requests/2 (2) https://github.com/mbien/winget-pkgs/tree/nb-25/manifests/a/Apache/NetBeans/25 (just as example; also see https://github.com/microsoft/winget-cli/issues/2299) On 3/25/25 16:39, Neil C Smith wrote: > Hi All, > > This follows some discussion threads here and on ASF Slack ... > > With branch for NetBeans 26 only 3 weeks away, we need to make a > decision soon about what release artefacts we're going to include > directly as part of the IDE's release process. > > Due to known issues with NBI we're currently not in a position to ship > a Windows installer for NetBeans 26 from Apache. There are other > issues that currently affect delivering a macOS installer. As we have > to rethink all this anyway, it probably makes it a good time to look > at all the things in the release process, what to keep, and how to > make things more manageable in future. > > My suggestion would be to limit the NetBeans IDE artefacts voted on > and directly delivered from Apache to - > > - Source zip > - Binary zip > - Maven artefacts > > This would mean dropping from the release vote and distribution - > > - All installers > > For installers we would point people at the community installers. > These are currently migrating to a new home, of which hopefully there > will be an announcement soon. There are also various other > third-party packages not produced by PMC members. We could keep the > ASF DEB and RPM packages with small overhead, mainly around testing, > but it probably makes more sense to drop all at once. > > - VSNetBeans > > I know Martin is currently working on a release schedule plan for > VSNetBeans to post here, so this might preempt that. A previous > discussion covered coordinating branch dates rather than release > dates. > > - NBMs and update centre > > This is all the NBMs published at > https://downloads.apache.org/netbeans/netbeans/25/nbms/ as well as the > update centre catalog XML on the NetBeans VM. These artefacts cause > some overhead in the release process but get almost no usage (checked > via https://infra-reports.apache.org ). An empty update centre XML > could actually make it easier to ship updates on the very rare > occasion we do so, and might even remove the need to use the VM at all > for this. The other use case for the UC is for optional downloads of > the platform for RCP apps using the legacy Ant build, but there are > other options there. It would also be possible to publish all these > later in case of unforeseen issues at time of release. > > Thoughts, or alternative solutions, welcomed. Let's try and get this > resolved in the next week or so, though. > > Thanks and best wishes, > > Neil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
