On Tue, 12 Nov 2024 at 12:16, Michael Bien <mbie...@gmail.com> wrote: > There were no specifics mentioned how a release would work or how often > it would happen. 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 ...
Generally I'm in favour of the same solution, but with a couple of changes / caveats. >... are initially based on a > NB release tag but can cherry pick from apache/netbeans#master and > release as often as needed > ... > - 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. I think the VSCode extension should be branched from master, not the release. I think branching from the release could just make things more difficult on both sides, and not meet the decoupling requirement. The whole point of our current time-based release strategy is that master should be kept in a generally releaseable state. Ideally we would share a branch date and hash with the VSCode plugin for the IDE release, and they can branch on other dates as advertised and required. Ideally their schedule is also time-based and pre-advertised. I also think that the VSCode plugin must only cherry pick from master. We will have to carefully coordinate during release period overlaps as fixes that need to also go into the IDE during releases would have to go into delivery, then master, before being cherry picked. > - 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 The implementation version is already based on the git hash. We need to ensure the plugin gets its own prefix. Spec versions on the other hand will overlap, but I don't see that as too much of an issue unless they "escape" into the wild? Other options there are not much better - too much pain for minimal gain? 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
