Hi > On 1. 11. 2024, at 14:15, Neil C Smith <neilcsm...@apache.org> wrote: > > 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. Yes, the job was updated and it builds currently what is officially used to build NetBeans and then VSNetBeans, no Rust. It was one time mistake. > > 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.
If VSNetBeans is separate product then it likely makes sense to release Source code artefact which corresponds to what is built into VSNetBeans. So it matches. > > Does VSNetBeans really need a metabuild file at all? I don’t think it needs meta build file. If this is not a requirement then yes skip it. > 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 cannot remember it either. We care since Micronaut support was added ~3 years ago :-( > > 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. I agree. If this is the next step in our discussion here I can prepare it. Martin > >> 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 > > >
