There's one thing I'd like to point out: the VS Code extension is only a thin wrapper over the main NetBeans code. So, many fixes (or improvements, although that has much smaller impact) to the extension require change to the main NetBeans code.
Hence, having a separate repository might help with some of the issues, but likely not all. E.g. a release of the extension is likely to require a branch in the mainline - unless the extension's repository would a) contain a copy of the full NetBeans code; or b) would contain patches to the main NetBeans code - both of which seem quite undesirable to me. For example, if there would be a repository for the VS Code extension with the main netbeans repository as a submodule, the minimal such repository could only contain build.xml, delegating to netbeans/java/java.lsp.server, and a README, nearly all the development would still happen in the main repository, and releases would likely require branch in the repository, etc. Jan On Sun, Nov 10, 2024 at 1:40 PM Michael Bien <mbie...@gmail.com> wrote: > On 01.11.24 13:17, Martin Balín wrote: > > > >> On 30. 10. 2024, at 16:26, Neil C Smith <neilcsm...@apache.org> wrote: > >> > >> On Wed, 30 Oct 2024 at 13:46, Eric Barboni <sk...@apache.org> wrote: > >>> How would it works during delivery branching phase on the main repo > with spec increment and so on? The others products have their own git > that's easy 😃 > >> I share this concern. The current situation causes enough of a > >> problem. If the release is entirely decoupled, then we really need to > >> look at decoupling it entirely from the Jenkns triggers and metabuild > >> info for the IDE. That might ideally take the form of a separate repo > >> that links to a specific hash on master for IDE artefacts, builds > >> sources from that for voting, and from them the plugin? A separate > >> repo could also have its own issue queue, etc. which might also be > >> good to decouple (different userbase, milestones, etc.) > > 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. > > this will likely cause github CI cache overflows when both releases > overlap. Cache is typically maxed out at nearly 10 GB when master and > delivery are active at the same time. > > I have a hard time imagining how this will actually work in practice. > How will git tags work when two products share one repo? NB generates > its release notes based on PR labels + tag deltas right now - I suppose > this won't be decoupled? One delivery branch is already causing issues > (see other thread) - I don't want to know what happens when PRs have to > be moved between two release branches and master. > > Having one schedule did avoid many issues so far. I think having one > repo but two concurrent schedules will increase friction even further > since it is essentially fighting the github infrastructure. > > "javavscode" for example went the git submodule route and it appears as > if the project is able to release as often as desired. > > https://github.com/oracle/javavscode/blob/main/.gitmodules > > -mbien > > > >> OTOH, there's also the GitHub workflows that build the launcher and > >> other natives. They might offer a model for handling this in repo. > >> > >> In general, I think decoupling the schedules might make some sense. > >> At the moment the interim releases reflect the bulk of the changes as > >> they tend to happen only a few weeks before freeze. > >> > >> Of course, there is a question of why we need the additional releases? > >> I also think there's an argument for only releasing the VSCode > >> releases in line with the IDE. The first interim release was called a > >> one-off. I feel like some of the picture is still missing here. > >> Whatever happens, the full schedule and reasons behind it need > >> discussing here on dev@. Will it be likewise time-based? Or driven > >> by something else? > > 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. > >> It seems to me that we're already struggling with capacity for > >> delivering releases of the IDE. Any decoupling of the VSCode plugin > >> needs to not make that situation worse or take any further focus away > >> from ensuring timely IDE releases. No IDE, no VSCode plugin. > > I have no problem helping with main NetBeans release. Decoupling > VSNetBeans can make it easier to release major NetBeans - simpler build > etc. VSNetBeans can be released with major NetBeans every time this > releases but as separate release. > > 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. > > > > Martin > > > >> 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 > >> > >> > >> > > > > --------------------------------------------------------------------- > > 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 > > > > > > > > > --------------------------------------------------------------------- > 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 > > > >
