On 12.11.24 14:52, Martin Balin wrote:
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?
The above described method would copy the release branch of the netbeans
repo into the new repo on every _NetBeans_ release, VSNetBeans would
then cherry pick from /netbeans#master into that branch and release from
there as frequent as needed. On next NB release a new copy is created.
This is no fork since development remains upstream first.
I mentioned at the end of the mail that this _could_ also simply fork
from master at random times and also why I am not a big fan of this idea.
- 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
I have to disagree here. Versions matter. org-openide-util-lookup should
be identical if the module version is the same no matter what release it
is in. Whether a plugin portal is involved is secondary IMO.
-mbien
- 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
---------------------------------------------------------------------
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
