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
