On 06.10.23 09:56, Antonio wrote:
P.S.: Since these binaries have a different release cycle than the
rest of the code (I think we could compile them one/two three times a
year, right?) we could create a new repository "netbeans-binaries" to
build these (having the NetBeans repo as a submodule). There's no need
to build these on each one of the PR submits, right?
the native lib workflows are only triggered when the PR diff includes a
change in that area. The main workflow uses the released libs like any
other regular dependency.
Lets say someone stages a new profiler lib build:
1) build the updated profiler lib and upload it somewhere (doesn't
really matter since it is for testing)
2) create a PR which uses the staged library with NB profiler tests
enabled to proof it works + dev-build label for easy manual testing
3) vote for the lib update, upload the lib to the official location
(apache, maven ...)
4) and update the PR from 2) to use the released version, wait for
tests, merge -> nb uses the new lib
Having them in a separate repo wouldn't make this easier IMO. It would
essentially invert the problem since the netbeans repo would now be a
submodule in the native-lib repo.
-mbien
---------------------------------------------------------------------
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
