Hi, On Fri, 1 Nov 2024 at 12:17, Martin Balín <mart...@windowslive.com> wrote: > How to release it as separate product > VSNetBeans might not be just build by main NetBeans release builds going > forward. Remove that step from build jobs. > And use separate release meta json vsnetbeansrelease.json. > Re delivery branch usage. VSNetBeans should have own branch from master with > whatever is in at the time of branching.
It at least looks like the existing Jenkins job has been updated to build the binaries from the source zip now? That at least covers a part of why I suggested looking at the GH workflows, although they're more strongly segregated. I still think might be worth looking at moving over, as we have discussed for the IDE. The other thing that should perhaps be looked at is ensuring the source bundle only contains the code required to build the VSCode plugin. Hopefully we won't accidentally release the Rust cluster again, but perhaps if releases are entirely separated a distinct cluster config for VSCode might be a good idea. Does VSNetBeans really need a metabuild file at all? Releasing all modules with dev-GITHASH implementation versions ties up better with their status? Embedding versions that diverge from the IDE might end up causing confusion in future with logs, etc. Using a separate repo would at least give distinct issue queue and milestones, which might be necessary to reduce confusion with IDE releases. > Releases of VSNetBeans are driven by faster release cycle in VS Code > marketplace in general. This is supported by simple creation of VSIX e.g. no > Update centers. Second driver is Micronaut support. Micronaut releases > frequently. Usually features added for Micronaut are beneficial for whole IDE > Java subsystem. Which includes also support for latest Java features done by > Jan and others. Yes, I know that. But I cannot remember a thread here where we mentioned caring about Micronaut releases for instance?! ;-) I think there should be a documented process and criteria for releases, similar to how the IDE release schedule was written, that is agreed here by lazy consensus. > The problem with release is not the capacity in release. It is lack of > testing and struggling in cutting what gets into release on time. Sure, we have no capacity problem in releases if we take out some of the major, key tasks of doing releases! :-) 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