Hi, > On 12. 11. 2024, at 13:11, Michael Bien <mbie...@gmail.com> wrote: > > There were no specifics mentioned how a release would work or how often it > would happen.
I would like to specify it including versioning schema once we have discussion on how to technically do it settled. > But taking your points into account, there are still some other options left > I think: > > for example analog to JDK update release repos (but simplified and just one > additional repo) > > - development remains in apache/netbeans#master > - apache/nb-vscode-ext#vs_release_x branches are initially based on a NB > release tag but can cherry pick from apache/netbeans#master and release as > often as needed This schema looks to me like fork of NetBeans master which is synced everytime new release of VSNetBeans is done. Did I got it correctly? > - on next NB release the branch is retired and a fresh branch is created > - all "code forge" aspects can be customized for the vscode extension needs > (issues, readme, CI, etc) Looks more or less OK for the purpose of releasing and not overloading current NetBeans GH project (GH caches problem). When thinking about VSNetBeans release I never had in mind doing another delivery branch for it. Just branch for VSNetbeans release e.g. vsnetbeans_2420, and create PRs to master and then cherrypick to this release branch. Lightweight release model compared to NetBeans IDE releases. Just to mention it here. > > I think the NB VSCode extension is at about 270MB right now, this is more > than half of the NetBeans release zip. From birds eye view it could be seen > as downstream distribution (custom packaging with about half of the NB > modules) with additional update releases in between. > > two more points I would like to bring up: > > - module versioning is essentially broken if any releases happen outside of > the NetBeans schedule. A module in netbeans can have different content as the > same module in the VSCode extension while carrying the same version -> there > probably needs to be another version component which is git hash or > distribution based to deconflict Module versioning in VSCode extension does not play significant role as when we need to patch something in NB code then whole VSCode extension is released, includes all modules. No Update centres are used. Martin > > - even if it could be done with the example above, I personally don't really > like the idea of branching master at random points. This is completely > sidelining the stabilization phase and major versions carry no significance > anymore. But if this is the intention I am not going to block it or anything > like that. There is also an argument to be made that the RC/stabilization > phase makes only sense if everyone who is using the mechanism is actually > caring about stabilization rules and the schedule. If the vscode repo would > be able to simply cherry pick from master, we might not have 5 accidental (?) > merges to delivery this release. > > best regards, > > michael > > On 10.11.24 18:43, Jan Lahoda wrote: >> 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 >>> >>> >>> >>> > --------------------------------------------------------------------- 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
