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



Reply via email to