You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Neil C Smith <ne...@apache.org> on 2026/06/04 13:25:02 UTC
How do you solve a problem like installers?
I want to have a frank discussion about installers, and what our plan
should be for NetBeans 31 and beyond. This follows up on some
conversation already elsewhere, such as Slack. I originally talked
about providing community installers for a further year while things
got resolved. That would make NetBeans 31 the last. Resolution does
not seem to be getting any nearer right now. We need to work out a
plan here, and we probably have 3 options -
- Drop all installers / leave to independent packagers. May not be
ideal, around ~60% of our user base use installers. Third-parties
with no connection here remove oversight - unsupported configs, more
bug reports for us! And some, like winget, just link to other
providers anyway.
- Bring back into ASF. This would remove the bundled JDK option, and
issues around code signing to resolve from the thread I started on the
security-discuss list [1]. No JDK is at least a possible option on
Windows now with changes elsewhere since we dropped the legacy NBI
installers, but there are some edge cases to resolve. The amount of
work may be a potential problem. I can donate my workflow here if
useful, but there is work to do to adapt to ASF's signing requirements
and properly test no-JDK Windows support in NBPackage.
- Bring the Friends of Apache NetBeans installers into line with the
community installer requirements [2], with possible PMC discussion /
decision on changing those requirements. The original plan was that
FoAN hosted shared infrastructure for these that PMC members could
access. That has still not happened. And whatever happens here, the
FoAN installers cannot continue being unaligned with the PMC
requirement - I don't think thousands of Windows users getting a
pre-released package or a package in an unsupported configuration is
OK.
Any thoughts? Other options to explore?
If we go with the latter two options, I'll continue to provide
community installers for NB31 as a backup option. If we go with the
first option, I'd probably stop after this one.
[1] Thread from March on security-discuss about access to ASF's code
signing in a GitHub workflow given our lack of reproducible builds -
https://lists.apache.org/thread/y72098wsxxg6504mll6qkc23sq37lmcp
[2] The community installer definition that has existed since 2022
amounts to "NetBeans packages bundled with the latest, recommended
JDK, built, tested and signed off by a PMC member". It's what we
agreed to point people to when dropping ASF built installers last
March.
Thanks and best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: How do you solve a problem like installers?
Posted by Geertjan Wielenga <ge...@googlemail.com>.
I'm in favor of the "Bring the Friends of Apache NetBeans installers into
line with the community installer requirements" idea.
That is, and has always been the intention. From where I've been involved
and seen the activity and otherwise, the only blocker has been
misunderstandings and miscommunications, nothing other than that, both
fortunately and unfortunately.
Gj
On Thu, Jun 4, 2026 at 3:25 PM Neil C Smith <ne...@apache.org> wrote:
> I want to have a frank discussion about installers, and what our plan
> should be for NetBeans 31 and beyond. This follows up on some
> conversation already elsewhere, such as Slack. I originally talked
> about providing community installers for a further year while things
> got resolved. That would make NetBeans 31 the last. Resolution does
> not seem to be getting any nearer right now. We need to work out a
> plan here, and we probably have 3 options -
>
> - Drop all installers / leave to independent packagers. May not be
> ideal, around ~60% of our user base use installers. Third-parties
> with no connection here remove oversight - unsupported configs, more
> bug reports for us! And some, like winget, just link to other
> providers anyway.
>
> - Bring back into ASF. This would remove the bundled JDK option, and
> issues around code signing to resolve from the thread I started on the
> security-discuss list [1]. No JDK is at least a possible option on
> Windows now with changes elsewhere since we dropped the legacy NBI
> installers, but there are some edge cases to resolve. The amount of
> work may be a potential problem. I can donate my workflow here if
> useful, but there is work to do to adapt to ASF's signing requirements
> and properly test no-JDK Windows support in NBPackage.
>
> - Bring the Friends of Apache NetBeans installers into line with the
> community installer requirements [2], with possible PMC discussion /
> decision on changing those requirements. The original plan was that
> FoAN hosted shared infrastructure for these that PMC members could
> access. That has still not happened. And whatever happens here, the
> FoAN installers cannot continue being unaligned with the PMC
> requirement - I don't think thousands of Windows users getting a
> pre-released package or a package in an unsupported configuration is
> OK.
>
> Any thoughts? Other options to explore?
>
> If we go with the latter two options, I'll continue to provide
> community installers for NB31 as a backup option. If we go with the
> first option, I'd probably stop after this one.
>
> [1] Thread from March on security-discuss about access to ASF's code
> signing in a GitHub workflow given our lack of reproducible builds -
> https://lists.apache.org/thread/y72098wsxxg6504mll6qkc23sq37lmcp
>
> [2] The community installer definition that has existed since 2022
> amounts to "NetBeans packages bundled with the latest, recommended
> JDK, built, tested and signed off by a PMC member". It's what we
> agreed to point people to when dropping ASF built installers last
> March.
>
> Thanks and best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: How do you solve a problem like installers?
Posted by Geertjan Wielenga <ge...@googlemail.com>.
Agreed, Matthias.
Gj
On Mon, Jun 15, 2026 at 11:58 PM Matthias Bläsing <mb...@doppel-helix.eu>
wrote:
> Hi,
>
> Am Sonntag, dem 07.06.2026 um 19:43 +0200 schrieb Geertjan Wielenga:
> > It’s just me, Pieter, and Timon. With the idea of working towards a
> > reproducible Apache NetBeans approved process for generating installers
> and
> > gathering funds and potentially enabling the providing of support. But
> all
> > things take time.
>
> my take aways from the points raised are:
>
> * FoN is a small group, that is willing to work with the PMC
> * The JDK bundled with FoN build should be a JDK matching
> OpenJDK, without additional modules
> * The ASF release process is what must finish before publication of
> the FoN build can happen.
> * Requests from the PMC should be honoured, especially if it concerns
> potentially distributing unreleased binaries
> * FoN should not distribute NetBeans without JDK
>
> This does not sound that undoable?!
>
> Greetings
>
> Matthias
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: How do you solve a problem like installers?
Posted by Neil C Smith <ne...@apache.org>.
Hi,
On Sun, 21 Jun 2026 at 22:43, Laszlo Kishalmi <la...@gmail.com> wrote:
> I do not feel that the PMC should extend its reach and sign/test third
> party distributions. As on NB we could provide a list, on parties, those
> provides binary installers, though probably shall not favor any.
Thanks Laszlo for your input. However, I'm unsure about this point.
Either this assumes a proposal to do something new, or it ignores what
we have already been doing for ~5 years?! There has never been a
proposal for the PMC, as a whole, to extend its reach in this way.
Community installers are produced by individual PMC members.
On our download pages we list two sources of community installers -
https://netbeans.apache.org/front/main/download/nb30/#_installers_and_packages
The Snap is produced, tested and signed off by you. The others have
been produced, tested and signed off by me since 2021 (including when
distributed via FoAN last year). They align with our release
processes - some of these used to be built in parallel on the same
hardware as the ASF installers. We have never listed just any
third-party on our download pages - see the notice in the linked
section.
I realise that the Snap is a little different. This was discussed
last year, eg. in
https://lists.apache.org/thread/ydl1nv75y2sbln86cnjssb007q2ynvo5 If
they move elsewhere, they could still be listed as long as they
continue to be produced by you or another PMC member.
A major point of the FoAN community installer transition was to have
them where other individual PMC members could be given access to build
and verify. That is not really any different from opening up access
to other PMC members to build and verify the Snap.
> Looking at Codelerity, creating packages with Eclipse Temurin JDK.
> The site it seems be more complete.
The switch from Zulu to Temurin was because I originally built the
NB28 ones for my own use, and then decided to publish later because we
didn't have anything else to link to. I've had a long standing issue
with the license text in Zulu. Temurin also happens to be smaller.
The installer page has remained largely the same since Geertjan and I
first started producing these in 2021. The original FoAN installer
site last year was essentially a carbon copy of this page.
> I recognize that this could lead to fragmentation of binaries. My view
> on that has shifted during the recent years. I think that's not
> necessary a bad thing.
Yes, we could stop all linking to installers on our download pages.
This is effectively the Option 1 in my original email, and I would
cease producing installers after this release. Where we list possible
links for users, and how we verify the suitability of those we list,
is open to debate. Note that the majority (60+%, 250,000+) of our
user base chooses installers over the zip. This would be an even
bigger disruption for them than when we stopped ASF installers last
year.
It would also imply that FoAN ceases all installer distribution from
NB 31, at least until there's agreement from us on using our identity
for something else (see also private@)
> I could imagine a company or an university would
> create a binary without ergonomics, releasing a pure Java or PHP IDEs,
> solely PHP development or education purposes.
Aside - yes, this is something I planned to experiment with once my
build repo isn't required for the standard installers. I wrote image
filtering into NBPackage partly with this in mind. Given we are
unlikely to have a reproducible build any time in the near future,
these could still then be built from the official binary zip with the
benefit of the payload remaining binary comparable with the ASF
release.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: How do you solve a problem like installers?
Posted by Laszlo Kishalmi <la...@gmail.com>.
On 6/21/26 14:44, Geertjan Wielenga wrote:
> No one on FoN is associated with Azul (anymore). :-) No preferred anything.
>
> It’s an attempt to provide a repo we can all contribute to together.
Well, that would be fine, the site needs some work then.
>
> Gj
>
> On Sun, 21 Jun 2026 at 23:42, Laszlo Kishalmi <la...@gmail.com>
> wrote:
>
>> Well, I have some concerns on FoN. According to their main page it's a
>> group of 3 people, possibly affiliated with Azul Systems (as a preferred
>> JDK Vendor). The main page states the latest version they provided was
>> NetBeans 28.
>>
>> From the outside, it does not seem to function well at the moment.
>>
>> Looking at Codelerity, creating packages with Eclipse Temurin JDK.
>> The site it seems be more complete.
>>
>> I do not feel that the PMC should extend its reach and sign/test third
>> party distributions. As on NB we could provide a list, on parties, those
>> provides binary installers, though probably shall not favor any.
>>
>> I would really move the Snap packages out of Apache, though I'm not sure
>> that FoN would be the place to move.
>>
>> I recognize that this could lead to fragmentation of binaries. My view
>> on that has shifted during the recent years. I think that's not
>> necessary a bad thing. I could imagine a company or an university would
>> create a binary without ergonomics, releasing a pure Java or PHP IDEs,
>> solely PHP development or education purposes.
>>
>>
>> On 6/16/26 02:11, Neil C Smith wrote:
>>> On Mon, 15 Jun 2026 at 22:58, Matthias Bläsing
>>> <mb...@doppel-helix.eu> wrote:
>>>> Am Sonntag, dem 07.06.2026 um 19:43 +0200 schrieb Geertjan Wielenga:
>>>>> It’s just me, Pieter, and Timon. With the idea of working towards a
>>>>> reproducible Apache NetBeans approved process for generating
>> installers and
>>>>> gathering funds and potentially enabling the providing of support. But
>> all
>>>>> things take time.
>>>> my take aways from the points raised are:
>>>>
>>>> * FoN is a small group, that is willing to work with the PMC
>>>> * The JDK bundled with FoN build should be a JDK matching
>>>> OpenJDK, without additional modules
>>>> * The ASF release process is what must finish before publication of
>>>> the FoN build can happen.
>>>> * Requests from the PMC should be honoured, especially if it concerns
>>>> potentially distributing unreleased binaries
>>>> * FoN should not distribute NetBeans without JDK
>>>>
>>>> This does not sound that undoable?!
>>> Agreed, although this misses one other point which I consider at least
>>> as important. Community installers should be built, tested and signed
>>> off by a PMC member. That is fundamentally different from independent
>>> third-party installers. They are produced and advertised in sync with
>>> our release candidates and releases.
>>>
>>> The point of migrating the installers from me (Codelerity) to FoAN,
>>> when people wanted them to be the primary installers, was two-fold.
>>> Remove Codelerity as the responsible entity (which I've been trying to
>>> do for years and still hasn't happened) and allow opening up build
>>> access to other PMC members so our linked installers are not tied to
>>> one person. This was discussed in multiple threads here before.
>>>
>>> *If* we decide or vote on an alternative to the PMC requirement, then
>>> we need to know how the installers will be tested and signed off, how
>>> syncing will work, and how we don't just land maintenance issues
>>> upstream given installer issues affecting the IDE or packager cannot
>>> then be resolved directly by the person doing the installer release.
>>>
>>> If we don't change the criteria, then as I said earlier, the workload
>>> for the PMC of running installers here or externally is really the
>>> same. Ignoring the initial setup to bring them back or whether
>>> non-JDK installers are actually desirable.
>>>
>>> There are 66 PMC members who could run this process, two of whom are
>>> involved directly in FoAN. There are 83 committers if we expanded the
>>> pool of people to them. To quote you - this does not sound that
>>> undoable?!
>>>
>>> Best wishes,
>>>
>>> Neil
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:dev-unsubscribe@netbeans.apache.org
>>> For additional commands, e-mail:dev-help@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-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: How do you solve a problem like installers?
Posted by Geertjan Wielenga <ge...@googlemail.com>.
No one on FoN is associated with Azul (anymore). :-) No preferred anything.
It’s an attempt to provide a repo we can all contribute to together.
Gj
On Sun, 21 Jun 2026 at 23:42, Laszlo Kishalmi <la...@gmail.com>
wrote:
> Well, I have some concerns on FoN. According to their main page it's a
> group of 3 people, possibly affiliated with Azul Systems (as a preferred
> JDK Vendor). The main page states the latest version they provided was
> NetBeans 28.
>
> From the outside, it does not seem to function well at the moment.
>
> Looking at Codelerity, creating packages with Eclipse Temurin JDK.
> The site it seems be more complete.
>
> I do not feel that the PMC should extend its reach and sign/test third
> party distributions. As on NB we could provide a list, on parties, those
> provides binary installers, though probably shall not favor any.
>
> I would really move the Snap packages out of Apache, though I'm not sure
> that FoN would be the place to move.
>
> I recognize that this could lead to fragmentation of binaries. My view
> on that has shifted during the recent years. I think that's not
> necessary a bad thing. I could imagine a company or an university would
> create a binary without ergonomics, releasing a pure Java or PHP IDEs,
> solely PHP development or education purposes.
>
>
> On 6/16/26 02:11, Neil C Smith wrote:
> > On Mon, 15 Jun 2026 at 22:58, Matthias Bläsing
> > <mb...@doppel-helix.eu> wrote:
> >> Am Sonntag, dem 07.06.2026 um 19:43 +0200 schrieb Geertjan Wielenga:
> >>> It’s just me, Pieter, and Timon. With the idea of working towards a
> >>> reproducible Apache NetBeans approved process for generating
> installers and
> >>> gathering funds and potentially enabling the providing of support. But
> all
> >>> things take time.
> >> my take aways from the points raised are:
> >>
> >> * FoN is a small group, that is willing to work with the PMC
> >> * The JDK bundled with FoN build should be a JDK matching
> >> OpenJDK, without additional modules
> >> * The ASF release process is what must finish before publication of
> >> the FoN build can happen.
> >> * Requests from the PMC should be honoured, especially if it concerns
> >> potentially distributing unreleased binaries
> >> * FoN should not distribute NetBeans without JDK
> >>
> >> This does not sound that undoable?!
> > Agreed, although this misses one other point which I consider at least
> > as important. Community installers should be built, tested and signed
> > off by a PMC member. That is fundamentally different from independent
> > third-party installers. They are produced and advertised in sync with
> > our release candidates and releases.
> >
> > The point of migrating the installers from me (Codelerity) to FoAN,
> > when people wanted them to be the primary installers, was two-fold.
> > Remove Codelerity as the responsible entity (which I've been trying to
> > do for years and still hasn't happened) and allow opening up build
> > access to other PMC members so our linked installers are not tied to
> > one person. This was discussed in multiple threads here before.
> >
> > *If* we decide or vote on an alternative to the PMC requirement, then
> > we need to know how the installers will be tested and signed off, how
> > syncing will work, and how we don't just land maintenance issues
> > upstream given installer issues affecting the IDE or packager cannot
> > then be resolved directly by the person doing the installer release.
> >
> > If we don't change the criteria, then as I said earlier, the workload
> > for the PMC of running installers here or externally is really the
> > same. Ignoring the initial setup to bring them back or whether
> > non-JDK installers are actually desirable.
> >
> > There are 66 PMC members who could run this process, two of whom are
> > involved directly in FoAN. There are 83 committers if we expanded the
> > pool of people to them. To quote you - this does not sound that
> > undoable?!
> >
> > Best wishes,
> >
> > Neil
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:dev-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail:dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: How do you solve a problem like installers?
Posted by Laszlo Kishalmi <la...@gmail.com>.
Well, I have some concerns on FoN. According to their main page it's a
group of 3 people, possibly affiliated with Azul Systems (as a preferred
JDK Vendor). The main page states the latest version they provided was
NetBeans 28.
From the outside, it does not seem to function well at the moment.
Looking at Codelerity, creating packages with Eclipse Temurin JDK.
The site it seems be more complete.
I do not feel that the PMC should extend its reach and sign/test third
party distributions. As on NB we could provide a list, on parties, those
provides binary installers, though probably shall not favor any.
I would really move the Snap packages out of Apache, though I'm not sure
that FoN would be the place to move.
I recognize that this could lead to fragmentation of binaries. My view
on that has shifted during the recent years. I think that's not
necessary a bad thing. I could imagine a company or an university would
create a binary without ergonomics, releasing a pure Java or PHP IDEs,
solely PHP development or education purposes.
On 6/16/26 02:11, Neil C Smith wrote:
> On Mon, 15 Jun 2026 at 22:58, Matthias Bläsing
> <mb...@doppel-helix.eu> wrote:
>> Am Sonntag, dem 07.06.2026 um 19:43 +0200 schrieb Geertjan Wielenga:
>>> It’s just me, Pieter, and Timon. With the idea of working towards a
>>> reproducible Apache NetBeans approved process for generating installers and
>>> gathering funds and potentially enabling the providing of support. But all
>>> things take time.
>> my take aways from the points raised are:
>>
>> * FoN is a small group, that is willing to work with the PMC
>> * The JDK bundled with FoN build should be a JDK matching
>> OpenJDK, without additional modules
>> * The ASF release process is what must finish before publication of
>> the FoN build can happen.
>> * Requests from the PMC should be honoured, especially if it concerns
>> potentially distributing unreleased binaries
>> * FoN should not distribute NetBeans without JDK
>>
>> This does not sound that undoable?!
> Agreed, although this misses one other point which I consider at least
> as important. Community installers should be built, tested and signed
> off by a PMC member. That is fundamentally different from independent
> third-party installers. They are produced and advertised in sync with
> our release candidates and releases.
>
> The point of migrating the installers from me (Codelerity) to FoAN,
> when people wanted them to be the primary installers, was two-fold.
> Remove Codelerity as the responsible entity (which I've been trying to
> do for years and still hasn't happened) and allow opening up build
> access to other PMC members so our linked installers are not tied to
> one person. This was discussed in multiple threads here before.
>
> *If* we decide or vote on an alternative to the PMC requirement, then
> we need to know how the installers will be tested and signed off, how
> syncing will work, and how we don't just land maintenance issues
> upstream given installer issues affecting the IDE or packager cannot
> then be resolved directly by the person doing the installer release.
>
> If we don't change the criteria, then as I said earlier, the workload
> for the PMC of running installers here or externally is really the
> same. Ignoring the initial setup to bring them back or whether
> non-JDK installers are actually desirable.
>
> There are 66 PMC members who could run this process, two of whom are
> involved directly in FoAN. There are 83 committers if we expanded the
> pool of people to them. To quote you - this does not sound that
> undoable?!
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail:dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: How do you solve a problem like installers?
Posted by Neil C Smith <ne...@apache.org>.
On Mon, 15 Jun 2026 at 22:58, Matthias Bläsing
<mb...@doppel-helix.eu> wrote:
> Am Sonntag, dem 07.06.2026 um 19:43 +0200 schrieb Geertjan Wielenga:
> > It’s just me, Pieter, and Timon. With the idea of working towards a
> > reproducible Apache NetBeans approved process for generating installers and
> > gathering funds and potentially enabling the providing of support. But all
> > things take time.
>
> my take aways from the points raised are:
>
> * FoN is a small group, that is willing to work with the PMC
> * The JDK bundled with FoN build should be a JDK matching
> OpenJDK, without additional modules
> * The ASF release process is what must finish before publication of
> the FoN build can happen.
> * Requests from the PMC should be honoured, especially if it concerns
> potentially distributing unreleased binaries
> * FoN should not distribute NetBeans without JDK
>
> This does not sound that undoable?!
Agreed, although this misses one other point which I consider at least
as important. Community installers should be built, tested and signed
off by a PMC member. That is fundamentally different from independent
third-party installers. They are produced and advertised in sync with
our release candidates and releases.
The point of migrating the installers from me (Codelerity) to FoAN,
when people wanted them to be the primary installers, was two-fold.
Remove Codelerity as the responsible entity (which I've been trying to
do for years and still hasn't happened) and allow opening up build
access to other PMC members so our linked installers are not tied to
one person. This was discussed in multiple threads here before.
*If* we decide or vote on an alternative to the PMC requirement, then
we need to know how the installers will be tested and signed off, how
syncing will work, and how we don't just land maintenance issues
upstream given installer issues affecting the IDE or packager cannot
then be resolved directly by the person doing the installer release.
If we don't change the criteria, then as I said earlier, the workload
for the PMC of running installers here or externally is really the
same. Ignoring the initial setup to bring them back or whether
non-JDK installers are actually desirable.
There are 66 PMC members who could run this process, two of whom are
involved directly in FoAN. There are 83 committers if we expanded the
pool of people to them. To quote you - this does not sound that
undoable?!
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: How do you solve a problem like installers?
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi,
Am Sonntag, dem 07.06.2026 um 19:43 +0200 schrieb Geertjan Wielenga:
> It’s just me, Pieter, and Timon. With the idea of working towards a
> reproducible Apache NetBeans approved process for generating installers and
> gathering funds and potentially enabling the providing of support. But all
> things take time.
my take aways from the points raised are:
* FoN is a small group, that is willing to work with the PMC
* The JDK bundled with FoN build should be a JDK matching
OpenJDK, without additional modules
* The ASF release process is what must finish before publication of
the FoN build can happen.
* Requests from the PMC should be honoured, especially if it concerns
potentially distributing unreleased binaries
* FoN should not distribute NetBeans without JDK
This does not sound that undoable?!
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: How do you solve a problem like installers?
Posted by Geertjan Wielenga <ge...@googlemail.com>.
It’s just me, Pieter, and Timon. With the idea of working towards a
reproducible Apache NetBeans approved process for generating installers and
gathering funds and potentially enabling the providing of support. But all
things take time.
Gj
On Sun, 7 Jun 2026 at 19:21, Matthias Bläsing <mb...@doppel-helix.eu>
wrote:
> Hi,
>
> I think the best option would be to have the installers inside the
> project, but that might be only a long term goal and needs someone,
> that really wants that.
>
> Having an organisation that provides installer for NetBeans and is
> associated with the projects is IMHO the second best. If really only
> timing was the problem last time, I think that can indeed be improved.
>
> What I see as an issue is, that "Friends of NetBeans" is opaque. I
> found a handful of messages here (I did not check whether these were on
> private@ or dev@) about "them". I'm aware that most (all?) release
> communication, apart from the announcements, happens on the slack
> channel, so are the people doing the "Friends of NetBeans" releasers
> aware of that and integrated? Would it be a good idea to have them
> there?
>
> Greetings
>
> Matthias
>
> Am Donnerstag, dem 04.06.2026 um 14:25 +0100 schrieb Neil C Smith:
> > I want to have a frank discussion about installers, and what our plan
> > should be for NetBeans 31 and beyond. This follows up on some
> > conversation already elsewhere, such as Slack. I originally talked
> > about providing community installers for a further year while things
> > got resolved. That would make NetBeans 31 the last. Resolution does
> > not seem to be getting any nearer right now. We need to work out a
> > plan here, and we probably have 3 options -
> >
> > - Drop all installers / leave to independent packagers. May not be
> > ideal, around ~60% of our user base use installers. Third-parties
> > with no connection here remove oversight - unsupported configs, more
> > bug reports for us! And some, like winget, just link to other
> > providers anyway.
> >
> > - Bring back into ASF. This would remove the bundled JDK option, and
> > issues around code signing to resolve from the thread I started on the
> > security-discuss list [1]. No JDK is at least a possible option on
> > Windows now with changes elsewhere since we dropped the legacy NBI
> > installers, but there are some edge cases to resolve. The amount of
> > work may be a potential problem. I can donate my workflow here if
> > useful, but there is work to do to adapt to ASF's signing requirements
> > and properly test no-JDK Windows support in NBPackage.
> >
> > - Bring the Friends of Apache NetBeans installers into line with the
> > community installer requirements [2], with possible PMC discussion /
> > decision on changing those requirements. The original plan was that
> > FoAN hosted shared infrastructure for these that PMC members could
> > access. That has still not happened. And whatever happens here, the
> > FoAN installers cannot continue being unaligned with the PMC
> > requirement - I don't think thousands of Windows users getting a
> > pre-released package or a package in an unsupported configuration is
> > OK.
> >
> > Any thoughts? Other options to explore?
> >
> > If we go with the latter two options, I'll continue to provide
> > community installers for NB31 as a backup option. If we go with the
> > first option, I'd probably stop after this one.
> >
> > [1] Thread from March on security-discuss about access to ASF's code
> > signing in a GitHub workflow given our lack of reproducible builds -
> > https://lists.apache.org/thread/y72098wsxxg6504mll6qkc23sq37lmcp
> >
> > [2] The community installer definition that has existed since 2022
> > amounts to "NetBeans packages bundled with the latest, recommended
> > JDK, built, tested and signed off by a PMC member". It's what we
> > agreed to point people to when dropping ASF built installers last
> > March.
> >
> > Thanks and best wishes,
> >
> > Neil
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
RE: [PUB] Re: How do you solve a problem like installers?
Posted by Eric Barboni <sk...@apache.org>.
I have no clear idea, but going forward is important.
On the RM side we have a non-opaque process listed in an issue + cwiki before trying to regroup each task.
Back in the installer phase we had a small period of test for installer (mostly the windows and macos) to be able to set up the vote.
Because we also had vote per installer incredibly costing time 😃.
And may cost asf money if you had to respin to frequently.
Slack is the most common RM phase chat as flooding dev ML for each step would be flooding a bit. We mail the main freeze, RCs and then vote.
We try to follow in order the checklist even if some topic can be done in parallel.
I did a lot of mistake timing issue and so one over the release. But we iterate to have best for next release.
It would be good FoAN could have such a list of task just clarify. What is trigger when.
Best Regards
Eric
-----Message d'origine-----
De : Neil C Smith <ne...@apache.org>
Envoyé : lundi 8 juin 2026 13:16
À : dev@netbeans.apache.org
Objet : [PUB] Re: How do you solve a problem like installers?
On Sun, 7 Jun 2026 at 18:21, Matthias Bläsing <mb...@doppel-helix.eu> wrote:
> I think the best option would be to have the installers inside the
> project, but that might be only a long term goal and needs someone,
> that really wants that.
Well, it would need a small team of people who want it. We have too
many release things that rely on one person already.
> Having an organisation that provides installer for NetBeans and is
> associated with the projects is IMHO the second best. If really only
> timing was the problem last time, I think that can indeed be improved.
Timing was a problem, but in some ways a lesser one - mistakes happen.
That the release was not taken down when pointed out, that it was
picked up by winget, and that thousands of Windows users got upgraded
from NB29 with a JDK to an unreleased NB30 without a JDK is a concern.
The process also needs review to ensure that publishing cannot happen
inadvertently in the future.
Multiple PMC members have raised issues with the JDK combinations on
offer (should just be JDK 26), and we agreed that a no-JDK installer
would only be released within the project, not externally. However,
the PMC is obviously free to agree to change its mind, if it wants to
....
> What I see as an issue is, that "Friends of NetBeans" is opaque. I
> found a handful of messages here (I did not check whether these were on
> private@ or dev@) about "them". I'm aware that most (all?) release
> communication, apart from the announcements, happens on the slack
> channel, so are the people doing the "Friends of NetBeans" releasers
> aware of that and integrated? Would it be a good idea to have them
> there?
Given almost all the release management work is falling on Eric these
days, I'm not sure how much he discusses this with himself on Slack!
:-) Joking aside, Michael and I do try and help out on a few things,
and that discussion does tend to happen there. Pieter is a guest on
the Slack channel. Any PMC member can obviously join.
That a PMC member considers FoAN opaque concerns me, but I agree that
the lack of PMC engagement is becoming an issue.
As I stated in my first email, we've had a community installer
definition that amounts to "NetBeans packages bundled with the latest,
recommended JDK, built, tested and signed off by a PMC member". That
has been discussed and reviewed as part of listing them over the
years. I have not deviated from that delivering the currently listed
installers, and would not without review. If the PMC wants to change
that definition, it can do. If someone wants us to, they can propose
something else. But that has to be a PMC decision to discuss and
agree.
The PMC also has responsibility for protecting the use of the name
Apache NetBeans. Pending an agreement on a Memorandum of
Understanding between the PMC and FoAN that the board recommended we
do 6 months ago, the distribution of community installers is the only
activity that could be said to have been consented to in any way by
the PMC. Maybe given your comment even that is a statement you'd
question? If FoAN is going to succeed, and I think it would be very
good if it did, the scope of its activity needs to be agreed with the
PMC. In my opinion, the Friends of Apache Groovy definition is a good
definition to consider, and certainly the transparency there would be
a good model to start from -
https://opencollective.com/friends-of-groovy#category-ABOUT Still,
FoAN has to propose something we can discuss and agree on.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: How do you solve a problem like installers?
Posted by Michael Bien <mb...@gmail.com>.
On 6/8/26 13:15, Neil C Smith wrote:
> Multiple PMC members have raised issues with the JDK combinations on
> offer (should just be JDK 26), and we agreed that a no-JDK installer
> would only be released within the project, not externally. However,
> the PMC is obviously free to agree to change its mind, if it wants to
> ....
I posted regarding JDK choice on the slack thread (and possibly also in other discussions), to bring it to the list:
- A lot of effort goes into keeping NetBeans runnable and usable on latest JDKs, both as IDE and platform. So far, we kept pace and the recommended runtime JDK was always the best available JDK at time of release [0].
/// recommended runtime JDK version
static int jdkVersion(int nb) {
return nb / 2 + 11;
}
-> the same recommended JDK version (also listed on the download page) should continue be the version used for the bundles.
(I remember the time when we had to ask on many issues to try again with the latest JDK release - the bundles reduced those requests significantly. Lets not add this indirection again - we know that not all JDK bugs are backported, esp on the desktop.)
- The vendors we can actually test on are also something to consider [1]. Ideally the bundles should be using a vendor we test on to reduce an indirection (again) and possible surprises.
- Similar rule applies for JDK modules: we (CI and vote threads as far as I see) test on the standard JDK distribution, not the JavaFX distribution. IMO there should be no need to offer a bundle which starts NB on a JDK including JavaFX right now.
btw nothing above is new or a change request. E.g the Codelerity bundles were always in sync with the download page. Its mostly a request to not change things which were working well in case someone else is taking over the bundles.
best regards,
michael
[0] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=255068881#MinimumJDKbuildandrunpolicy-Mnemonics(NB23+)
[1] https://github.com/apache/netbeans/blob/ab116ad98647f0a5ca3e52c4bcb53600411b7995/.github/workflows/main.yml#L68-L77
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: How do you solve a problem like installers?
Posted by Neil C Smith <ne...@apache.org>.
On Sun, 7 Jun 2026 at 18:21, Matthias Bläsing <mb...@doppel-helix.eu> wrote:
> I think the best option would be to have the installers inside the
> project, but that might be only a long term goal and needs someone,
> that really wants that.
Well, it would need a small team of people who want it. We have too
many release things that rely on one person already.
> Having an organisation that provides installer for NetBeans and is
> associated with the projects is IMHO the second best. If really only
> timing was the problem last time, I think that can indeed be improved.
Timing was a problem, but in some ways a lesser one - mistakes happen.
That the release was not taken down when pointed out, that it was
picked up by winget, and that thousands of Windows users got upgraded
from NB29 with a JDK to an unreleased NB30 without a JDK is a concern.
The process also needs review to ensure that publishing cannot happen
inadvertently in the future.
Multiple PMC members have raised issues with the JDK combinations on
offer (should just be JDK 26), and we agreed that a no-JDK installer
would only be released within the project, not externally. However,
the PMC is obviously free to agree to change its mind, if it wants to
....
> What I see as an issue is, that "Friends of NetBeans" is opaque. I
> found a handful of messages here (I did not check whether these were on
> private@ or dev@) about "them". I'm aware that most (all?) release
> communication, apart from the announcements, happens on the slack
> channel, so are the people doing the "Friends of NetBeans" releasers
> aware of that and integrated? Would it be a good idea to have them
> there?
Given almost all the release management work is falling on Eric these
days, I'm not sure how much he discusses this with himself on Slack!
:-) Joking aside, Michael and I do try and help out on a few things,
and that discussion does tend to happen there. Pieter is a guest on
the Slack channel. Any PMC member can obviously join.
That a PMC member considers FoAN opaque concerns me, but I agree that
the lack of PMC engagement is becoming an issue.
As I stated in my first email, we've had a community installer
definition that amounts to "NetBeans packages bundled with the latest,
recommended JDK, built, tested and signed off by a PMC member". That
has been discussed and reviewed as part of listing them over the
years. I have not deviated from that delivering the currently listed
installers, and would not without review. If the PMC wants to change
that definition, it can do. If someone wants us to, they can propose
something else. But that has to be a PMC decision to discuss and
agree.
The PMC also has responsibility for protecting the use of the name
Apache NetBeans. Pending an agreement on a Memorandum of
Understanding between the PMC and FoAN that the board recommended we
do 6 months ago, the distribution of community installers is the only
activity that could be said to have been consented to in any way by
the PMC. Maybe given your comment even that is a statement you'd
question? If FoAN is going to succeed, and I think it would be very
good if it did, the scope of its activity needs to be agreed with the
PMC. In my opinion, the Friends of Apache Groovy definition is a good
definition to consider, and certainly the transparency there would be
a good model to start from -
https://opencollective.com/friends-of-groovy#category-ABOUT Still,
FoAN has to propose something we can discuss and agree on.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: How do you solve a problem like installers?
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi,
I think the best option would be to have the installers inside the
project, but that might be only a long term goal and needs someone,
that really wants that.
Having an organisation that provides installer for NetBeans and is
associated with the projects is IMHO the second best. If really only
timing was the problem last time, I think that can indeed be improved.
What I see as an issue is, that "Friends of NetBeans" is opaque. I
found a handful of messages here (I did not check whether these were on
private@ or dev@) about "them". I'm aware that most (all?) release
communication, apart from the announcements, happens on the slack
channel, so are the people doing the "Friends of NetBeans" releasers
aware of that and integrated? Would it be a good idea to have them
there?
Greetings
Matthias
Am Donnerstag, dem 04.06.2026 um 14:25 +0100 schrieb Neil C Smith:
> I want to have a frank discussion about installers, and what our plan
> should be for NetBeans 31 and beyond. This follows up on some
> conversation already elsewhere, such as Slack. I originally talked
> about providing community installers for a further year while things
> got resolved. That would make NetBeans 31 the last. Resolution does
> not seem to be getting any nearer right now. We need to work out a
> plan here, and we probably have 3 options -
>
> - Drop all installers / leave to independent packagers. May not be
> ideal, around ~60% of our user base use installers. Third-parties
> with no connection here remove oversight - unsupported configs, more
> bug reports for us! And some, like winget, just link to other
> providers anyway.
>
> - Bring back into ASF. This would remove the bundled JDK option, and
> issues around code signing to resolve from the thread I started on the
> security-discuss list [1]. No JDK is at least a possible option on
> Windows now with changes elsewhere since we dropped the legacy NBI
> installers, but there are some edge cases to resolve. The amount of
> work may be a potential problem. I can donate my workflow here if
> useful, but there is work to do to adapt to ASF's signing requirements
> and properly test no-JDK Windows support in NBPackage.
>
> - Bring the Friends of Apache NetBeans installers into line with the
> community installer requirements [2], with possible PMC discussion /
> decision on changing those requirements. The original plan was that
> FoAN hosted shared infrastructure for these that PMC members could
> access. That has still not happened. And whatever happens here, the
> FoAN installers cannot continue being unaligned with the PMC
> requirement - I don't think thousands of Windows users getting a
> pre-released package or a package in an unsupported configuration is
> OK.
>
> Any thoughts? Other options to explore?
>
> If we go with the latter two options, I'll continue to provide
> community installers for NB31 as a backup option. If we go with the
> first option, I'd probably stop after this one.
>
> [1] Thread from March on security-discuss about access to ASF's code
> signing in a GitHub workflow given our lack of reproducible builds -
> https://lists.apache.org/thread/y72098wsxxg6504mll6qkc23sq37lmcp
>
> [2] The community installer definition that has existed since 2022
> amounts to "NetBeans packages bundled with the latest, recommended
> JDK, built, tested and signed off by a PMC member". It's what we
> agreed to point people to when dropping ASF built installers last
> March.
>
> Thanks and best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: How do you solve a problem like installers?
Posted by Neil C Smith <ne...@apache.org>.
On Mon, 8 Jun 2026 at 02:36, Michael Bien <mb...@gmail.com> wrote:
> This means that the second option ("Bring back into ASF") would be possible without disrupting downstream packaging since the JDK could be moved into a dependency (if it isn't already one like with AUR and flathub).
Possibly. You and I are amongst PMC members who have raised concerns
about FoAN shipping unsupported JDK combinations. With the zip bundle
it is very obviously designed to allow the end user to choose which
JDK to run the IDE with. With packages like that we would need to be
careful how the JDK dependency is resolved, particularly if the
installation makes this more difficult to configure (eg. netbeans.conf
being read-only). We sometimes had issues with this before.
It's worth noting Laszlo's comment on a recent Snap issue about the
benefit of moving that outside of ASF so that the JDK dependency could
be included - https://github.com/apache/netbeans/issues/9392#issuecomment-4558885625
> Of course the signing problem remains + someone would have to do that task during release which is already full with other tasks (looking at the new, slightly intimidating checklist).
For anyone interested, Eric's checklist of tasks for the current
release process is at
https://github.com/apache/netbeans-jenkins-lib/issues/146 We were
joking about how all this is the short version since
https://lists.apache.org/thread/w02bvdnzdorlsco2cpfyhvnkzbscydcz when
we dropped both installers and the update centers. This reduced some
of the release overhead.
The update centers were a significant job to remove. The macOS
installer was the bigger installer overhead, as it was the only one
that had to be built and signed manually.
If we were to bring installers back into ASF, we could use a workflow
like the one I currently use for the community installers -
https://github.com/codelerity/netbeans-packages That is the subject
of the discussion on the security-discuss list. That builds and signs
every installer in about 5min. The workload is making a process like
that ASF compliant to access the foundation's code signing. The
additional release overhead is there, but would be less than our
previous process. Testing and gpg sign off for vote would probably
need to be shared out.
The other point I would make is that a PMC member has been doing that
task during the release process for the last 18 months - me! FoAN
was meant to be providing infrastructure for PMC members to share
access to things that cannot be done within ASF. Assuming that is
made to work as intended, the release overhead should be similar
whether it's done internally or externally. Whether we can actually
do that with our current resources is part of this conversation.
Option #1 is the only one that removes workload.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: How do you solve a problem like installers?
Posted by Michael Bien <mb...@gmail.com>.
Hi,
I took another look at what the downstream packages were based on.
AUR + flathub are based on our bin-zip:
https://aur.archlinux.org/packages/netbeans-bin
https://github.com/flathub/org.apache.netbeans
Laszlo maintains the snap package, please correct me if I am wrong but I believe it is also taking the bin-zips for both channels
https://snapcraft.io/netbeans
winget and hombebrew both use the Friends of NetBeans jdk bundles
https://github.com/microsoft/winget-pkgs/tree/master/manifests/a/Apache/NetBeans/30
https://github.com/Homebrew/homebrew-cask/blob/main/Casks/n/netbeans.rb
I looked at winget around the NB 25 time frame, and remember that it supported dependencies and even zip packages (although zip packages had some limitations). Homebrew can handle dependencies too.
This means that the second option ("Bring back into ASF") would be possible without disrupting downstream packaging since the JDK could be moved into a dependency (if it isn't already one like with AUR and flathub).
Of course the signing problem remains + someone would have to do that task during release which is already full with other tasks (looking at the new, slightly intimidating checklist).
best regards,
-mbien
On 6/4/26 15:25, Neil C Smith wrote:
> I want to have a frank discussion about installers, and what our plan
> should be for NetBeans 31 and beyond. This follows up on some
> conversation already elsewhere, such as Slack. I originally talked
> about providing community installers for a further year while things
> got resolved. That would make NetBeans 31 the last. Resolution does
> not seem to be getting any nearer right now. We need to work out a
> plan here, and we probably have 3 options -
>
> - Drop all installers / leave to independent packagers. May not be
> ideal, around ~60% of our user base use installers. Third-parties
> with no connection here remove oversight - unsupported configs, more
> bug reports for us! And some, like winget, just link to other
> providers anyway.
>
> - Bring back into ASF. This would remove the bundled JDK option, and
> issues around code signing to resolve from the thread I started on the
> security-discuss list [1]. No JDK is at least a possible option on
> Windows now with changes elsewhere since we dropped the legacy NBI
> installers, but there are some edge cases to resolve. The amount of
> work may be a potential problem. I can donate my workflow here if
> useful, but there is work to do to adapt to ASF's signing requirements
> and properly test no-JDK Windows support in NBPackage.
>
> - Bring the Friends of Apache NetBeans installers into line with the
> community installer requirements [2], with possible PMC discussion /
> decision on changing those requirements. The original plan was that
> FoAN hosted shared infrastructure for these that PMC members could
> access. That has still not happened. And whatever happens here, the
> FoAN installers cannot continue being unaligned with the PMC
> requirement - I don't think thousands of Windows users getting a
> pre-released package or a package in an unsupported configuration is
> OK.
>
> Any thoughts? Other options to explore?
>
> If we go with the latter two options, I'll continue to provide
> community installers for NB31 as a backup option. If we go with the
> first option, I'd probably stop after this one.
>
> [1] Thread from March on security-discuss about access to ASF's code
> signing in a GitHub workflow given our lack of reproducible builds -
> https://lists.apache.org/thread/y72098wsxxg6504mll6qkc23sq37lmcp
>
> [2] The community installer definition that has existed since 2022
> amounts to "NetBeans packages bundled with the latest, recommended
> JDK, built, tested and signed off by a PMC member". It's what we
> agreed to point people to when dropping ASF built installers last
> March.
>
> Thanks and best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: How do you solve a problem like installers?
Posted by Geertjan Wielenga <ge...@googlemail.com>.
The idea is for Friends of Apache NetBeans to provide a centralized place
where PMC members can create and test installers for inclusion in the
Community Installers list on the Apache NetBeans download page.
The first round of this would ideally be for the release we're currently
working on, with the RC2 being the trial run for that. I'll be the PMC
member putting those installers together and testing them. The
infrastructure is there, thanks to Neil and Pieter, and where help is
needed I'll reach out to them for their respective insights.
I'll be tracking things closely to make sure this kicks off with the RC2
release.
Gj
On Fri, Jul 10, 2026 at 8:20 PM Michael Bien <mb...@gmail.com> wrote:
>
> On 6/4/26 15:25, Neil C Smith wrote:
> > I want to have a frank discussion about installers, and what our plan
> > should be for NetBeans 31 and beyond. This follows up on some
> > conversation already elsewhere, such as Slack. I originally talked
> > about providing community installers for a further year while things
> > got resolved. That would make NetBeans 31 the last. Resolution does
> > not seem to be getting any nearer right now.
>
> If you are still available to provide bundles/installers for the
> upcoming NB 31 release -> would be great.
>
> NB 32 and later might lose the installer links from the download page -
> dependant on the situation before release.
>
> -mbien
>
>
> > We need to work out a
> > plan here, and we probably have 3 options -
> >
> > - Drop all installers / leave to independent packagers. May not be
> > ideal, around ~60% of our user base use installers. Third-parties
> > with no connection here remove oversight - unsupported configs, more
> > bug reports for us! And some, like winget, just link to other
> > providers anyway.
> >
> > - Bring back into ASF. This would remove the bundled JDK option, and
> > issues around code signing to resolve from the thread I started on the
> > security-discuss list [1]. No JDK is at least a possible option on
> > Windows now with changes elsewhere since we dropped the legacy NBI
> > installers, but there are some edge cases to resolve. The amount of
> > work may be a potential problem. I can donate my workflow here if
> > useful, but there is work to do to adapt to ASF's signing requirements
> > and properly test no-JDK Windows support in NBPackage.
> >
> > - Bring the Friends of Apache NetBeans installers into line with the
> > community installer requirements [2], with possible PMC discussion /
> > decision on changing those requirements. The original plan was that
> > FoAN hosted shared infrastructure for these that PMC members could
> > access. That has still not happened. And whatever happens here, the
> > FoAN installers cannot continue being unaligned with the PMC
> > requirement - I don't think thousands of Windows users getting a
> > pre-released package or a package in an unsupported configuration is
> > OK.
> >
> > Any thoughts? Other options to explore?
> >
> > If we go with the latter two options, I'll continue to provide
> > community installers for NB31 as a backup option. If we go with the
> > first option, I'd probably stop after this one.
> >
> > [1] Thread from March on security-discuss about access to ASF's code
> > signing in a GitHub workflow given our lack of reproducible builds -
> > https://lists.apache.org/thread/y72098wsxxg6504mll6qkc23sq37lmcp
> >
> > [2] The community installer definition that has existed since 2022
> > amounts to "NetBeans packages bundled with the latest, recommended
> > JDK, built, tested and signed off by a PMC member". It's what we
> > agreed to point people to when dropping ASF built installers last
> > March.
> >
> > Thanks and best wishes,
> >
> > Neil
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: How do you solve a problem like installers?
Posted by Neil C Smith <ne...@apache.org>.
On Fri, 10 Jul 2026 at 19:19, Michael Bien <mb...@gmail.com> wrote:
> If you are still available to provide bundles/installers for the
> upcoming NB 31 release -> would be great.
As I said in the original email, I'm happy to provide installers for
NB31 if there's a clear and viable plan to move forward on options 2
or 3. I'm not going to put more of my time (and money) into this
process if there's no movement towards a sustainable path.
I had a chat with Geertjan last week, and I understand things are now
moving in the right direction. I hope with NB31 we'll finally see one
set of installers with the latest JDK, built, tested and verified by a
PMC member through the FoAN process.
I'll aim to provide installers for NB31 as a backup in case of
teething problems. I may not be able to make them for all RCs though
due to other commitments. I would prefer to see FoAN provide for RC1
so we can pick up issues sooner. And while smooth releases are good
to see, in some ways I'd like NB31 to be a release that requires
installer-related IDE or NBPackage fixes so we see how that can be
managed.
From my perspective I would also like to see the much delayed
Memorandum of Understanding between the PMC and FoAN in place before
NB31 is released, so we're all clear on the scope of activities that
FoAN can do while using our marks.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: How do you solve a problem like installers?
Posted by Michael Bien <mb...@gmail.com>.
On 6/4/26 15:25, Neil C Smith wrote:
> I want to have a frank discussion about installers, and what our plan
> should be for NetBeans 31 and beyond. This follows up on some
> conversation already elsewhere, such as Slack. I originally talked
> about providing community installers for a further year while things
> got resolved. That would make NetBeans 31 the last. Resolution does
> not seem to be getting any nearer right now.
If you are still available to provide bundles/installers for the
upcoming NB 31 release -> would be great.
NB 32 and later might lose the installer links from the download page -
dependant on the situation before release.
-mbien
> We need to work out a
> plan here, and we probably have 3 options -
>
> - Drop all installers / leave to independent packagers. May not be
> ideal, around ~60% of our user base use installers. Third-parties
> with no connection here remove oversight - unsupported configs, more
> bug reports for us! And some, like winget, just link to other
> providers anyway.
>
> - Bring back into ASF. This would remove the bundled JDK option, and
> issues around code signing to resolve from the thread I started on the
> security-discuss list [1]. No JDK is at least a possible option on
> Windows now with changes elsewhere since we dropped the legacy NBI
> installers, but there are some edge cases to resolve. The amount of
> work may be a potential problem. I can donate my workflow here if
> useful, but there is work to do to adapt to ASF's signing requirements
> and properly test no-JDK Windows support in NBPackage.
>
> - Bring the Friends of Apache NetBeans installers into line with the
> community installer requirements [2], with possible PMC discussion /
> decision on changing those requirements. The original plan was that
> FoAN hosted shared infrastructure for these that PMC members could
> access. That has still not happened. And whatever happens here, the
> FoAN installers cannot continue being unaligned with the PMC
> requirement - I don't think thousands of Windows users getting a
> pre-released package or a package in an unsupported configuration is
> OK.
>
> Any thoughts? Other options to explore?
>
> If we go with the latter two options, I'll continue to provide
> community installers for NB31 as a backup option. If we go with the
> first option, I'd probably stop after this one.
>
> [1] Thread from March on security-discuss about access to ASF's code
> signing in a GitHub workflow given our lack of reproducible builds -
> https://lists.apache.org/thread/y72098wsxxg6504mll6qkc23sq37lmcp
>
> [2] The community installer definition that has existed since 2022
> amounts to "NetBeans packages bundled with the latest, recommended
> JDK, built, tested and signed off by a PMC member". It's what we
> agreed to point people to when dropping ASF built installers last
> March.
>
> Thanks and best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists