Hi,
I'm missing something here! I'd appreciate some explanations.
We currently depend on exechlp-1.2.zip [1] for dlight.nativeexecution,
right? But nobody has voted _explicitly_ on that dependency.
We now build the new macos binaries for Apple Silicon, that we can
download from dist.apache.org and then include them as we do with
exechlp-1.2.zip.
And no extra voting is required, right?
Apple Silicon support is included in NB20 (downloading from
dist.apache.org) as well as exechlp-1.2.zip (downloading from OSOUL) and
everybody is happy, right? What's the problem?
Whenever we release NB20 we'll vote for the new release as we always do
(including those Apple Silicon binaries compiled from our own APLv2
sources). A single vote will do for everything. Why adding an extra vote?
Thanks for the explanations,
Antonio
P.S.: Same thing for profiler binaries.
[1]
https://github.com/apache/netbeans/blob/master/ide/dlight.nativeexecution/external/binaries-list
On 5/10/23 20:42, Neil C Smith wrote:
Unfortunately that means we will likely now not have Apple Silicon
support in NB20, unless someone else can pick it up, and also ironically
we will end up continuing with the existing profiler binary that is
*less* compliant with ASF release procedures. Our build process requires
the distribution of binary native artefacts to people building from
source. That source is not signed and is not voted on *at the point that
those binaries are produced*. Neither are the binaries. It's a chicken
and egg situation. Part of the release process is verifying the link
between source bundle and binary. This does that.
---------------------------------------------------------------------
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
