I in my opinion you should start with "release de-coupling". Changes to Git repository structure (while I never liked the "product" to reside so deeply hidden in `java/java.lsp.server/vscode`) aren't related to the release process (in fact they would only complicate the existing well functioning process of creating `.vsix` binary) and as such they may follow later.
-jt Dne sobota 9. listopadu 2024 10:18:34 CET, Michael Bien napsal(a): > On 30.10.24 16:26, Neil C Smith 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 > > overall I think decoupling both products could potentially reduce some > friction. But I agree here with Neil I think it should be "properly" > decoupled, including repo if possible. (/netbeans as git sub module > potentially?) > > The current situation isn't ideal since the NetBeans IDE stabilization > phase often overlaps or comes close to the NB VSCode plugin schedule. I > think there is also a release shortly before master is branched which > leads to the x.99 versioning I believe. > > It is always problematic if product A tries to stabilize while product B > is trying to integrate features and both share code. > > Having a separate repo might also benefit discoverability, simplify > issue tracking, allow quick patching before upstreaming etc. > > best regards, > > michael > > > 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.) > > > > 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? > > > > 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. > > > > 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
