Well, I'm on Option 1 for the upcoming NB25 and option 3 on longer run.
The way moving forward would probably worth a vote thread or at least a
call for lazy consensus.
On 2/3/25 07:53, Michael Bien wrote:
I like Option 1 too
(forgot to mention my preference)
best regards,
michael
On 03.02.25 16:41, Martin Balín wrote:
I would go with Option 1 - drop NBI windows, for NetBeans 25
The reason: don’t block current release. After the release evaluate
if NetBeans should provide other installers as well. Mean discuss if
Option3 would not be too disruptive.
Martin
On 3. 2. 2025, at 14:46, Michael Bien <mbie...@gmail.com> wrote:
What shall we do for NB 25 which is currently baking?
situation: unchanged
Should we drop NBI or do another release? The mentioned issues did
not progress. Users will likely have difficulties to uninstall NB
23/24 on windows. Those affected by it might also not be able to
install NB 25 due to broken installer configuration.
I used to test on win10/11 during vote but won't do that anymore
since I can't update the windows image to the latest version inside
virtualbox - I can't reproduce any of this anyway so its mostly
wasted time at this point I think.
option 1:
- drop NBI windows
- add a link down to the community installers for windows users
- keep all other installers for now
option 2:
- release everything again for one more release
option 3:
- drop everything except the zip
option 4: ?
best regards,
michael
On 07.01.25 20:57, Laszlo Kishalmi wrote:
On 1/7/25 10:25, Neil C Smith wrote:
There are two things to consider. Firstly, we could, and actually in
my opinion should, drop all the convenience installers and just
provide the binary zip. Installers that rely on system JDKs are
likely to become more problematic over time, given code signing,
sandboxing, permissions and other factors. I think if people want to
use a JDK of choice they should use the binary zip. That also means
potentially looking to improve the range and availability of
community
installers, besides or instead of the ones I'm producing I hasten to
add! That will involve continuing discussions somewhat
independent of
the project itself.
I agree on this one. Even if I considered having packages from the
single source of truth as value.
Holding to that simply getting too much burden on maintenance on
the other hand could be restrictive also could be inconvenient for
our users as well.
I would like to drop the Apache NetBeans Provided Snap packages as
well, move that to community. Apache restrictions, while being
reasonable, eventually hurt end-user experience.
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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