> 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. > > 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 > > >
