You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Martin Balín <ma...@windowslive.com> on 2024/11/01 12:17:04 UTC
Re: Apache NetBeans extension for Visual Studio Code
> On 30. 10. 2024, at 16:26, Neil C Smith <ne...@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.
>
> 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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
Re: Apache NetBeans extension for Visual Studio Code
Posted by Neil C Smith <ne...@apache.org>.
> > On 31. 1. 2025, at 17:31, Neil C Smith <ne...@apache.org> wrote:
> > Personally I'd also like to see a hard limit on the number of
> > VSNetBeans releases between IDE releases in case of release delays in
> > future.
> VSNetBeans releases in between IDE releases:
...
> And we also need to decide if VSNetBeans will be released as part of main NetBeans IDE release. Or it will be done separately by me (likely from same code). Both works for me.
OK, let's deal with the elephant in the room here first! No NetBeans
IDE, no VSNetBeans. No NetBeans IDE releases, no VSNetBeans releases.
If these projects are to remain developing and coexisting within a
single repository, then *everyone* working on that repository has to
take some shared responsibility for ensuring the delivery of *all* its
release components. The IDE, the VSCode plugin, and also the full
range of platform artefacts. That includes issue management, PR
reviews and rc testing across the board.
When you were invited on to the release team, the intention was to
share the release aspects of this workload out across the components.
As of yet, neither you nor anyone else from the VSCode side has led on
a full release or release candidate. Half of VSNetBeans' releases
have been via that process. That situation is just not sustainable.
When I took a break from the release team, I was hopeful that
everything would not be left to one person, Eric. We had discussions
around that, but from my perspective it doesn't feel like it's
resolved much.
Also, changes in the repository for VSNetBeans have a knock on effect
on the IDE and platform. The first vote for NetBeans 24 had to be
pulled because changes added solely (afaik) for the plugin caused a
serious issue. That was not a one-off. Pulling a vote delays the
full release by at least a week, and causes hours of extra work for
the release manager. One consequence of not sharing this workload
more fairly is going to be that people start vetoing changes in the
IDE's code that bring no discernible benefit to the IDE or platform.
Can I also be clear that personally I want this to work, and I want
the development to continue within the single overarching repository.
But unless we can realistically address the release capacity issue, it
will fall apart, and that's no use to anyone!
> Not sure I understand what you mean here Neil. Is it moving branching dates for VSNetBeans and NetBeans release earlier to same date? Branch both on e.g. Jan 11th when these releases could be overlapping like in a case of VSNetBeans 24.9.9 and NetBeans 25? Or move branching dates far apart? So in the case of VSNetBeans 24.9.9 will branch around Jan 6th to make sure it releases before Jan 15th when NetBeans 25 release branch would be created?
IMO they should share branch points as that makes it much easier on
both sides to understand what is included, and to stabilise towards
the point of branch. I also think, given another conversation today,
that reconsidering the IDE branch and release points in relation to
JDK releases would be a good thing anyway.
> What will be the purpose of such branching repo? Like fork of whole NetBeans code base on which VSNetBeans release will happen? Is this what you mean?
I think Michael put this quite well earlier in this thread?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Martin Balin <mb...@apache.org>.
> On 31. 1. 2025, at 17:31, Neil C Smith <ne...@apache.org> wrote:
>
> On Fri, 31 Jan 2025 at 16:05, Martin Balin <mb...@apache.org> wrote:
>> I’m asking this as using same date for NetBeans IDE and VSNetBeans branching (if these are close enough) was proposed earlier in this thread.
> ...
>> JDK releases are usually closer to 15th of the month therefore it will be better if VSNetBeans can branch ~ 10 days prior JDK days, from master, using vsnetBeans_xyz branch. (See proposed schedule below)
>
> And that proposal is still, IMO, how this should be done. Why not a
> change to the branch dates if you need it to be earlier, as was
> suggested? Having different branch dates too close together is going
> to be a problem for stability.
>
Not sure I understand what you mean here Neil. Is it moving branching dates for VSNetBeans and NetBeans release earlier to same date? Branch both on e.g. Jan 11th when these releases could be overlapping like in a case of VSNetBeans 24.9.9 and NetBeans 25? Or move branching dates far apart? So in the case of VSNetBeans 24.9.9 will branch around Jan 6th to make sure it releases before Jan 15th when NetBeans 25 release branch would be created?
>> Therefore delivery and vsnetBeans_xyz branch will coexist in some time slots during the year.
>
> That was expected. As long as everything going into master goes via
> delivery, that's not a problem. If you're cherry picking commits to
> vsnetbeans(?), you could cherry pick from whichever branch you want.
OK.
>
>> (Version tbd)
>
> It would be good to use separate version numbers, and a separate
> branching repo with your own issue queue, milestones, etc. This is
> already a point of confusion.
What will be the purpose of such branching repo? Like fork of whole NetBeans code base on which VSNetBeans release will happen? Is this what you mean?
I still think version numbers of VSNetBeans should relate to these “base IDE version numbers” from NetBeans IDE so people can understand what it was based on -> what features and fixes to expect from NB IDE.
And we also need to decide if VSNetBeans will be released as part of main NetBeans IDE release. Or it will be done separately by me (likely from same code). Both works for me.
>
> Personally I'd also like to see a hard limit on the number of
> VSNetBeans releases between IDE releases in case of release delays in
> future.
VSNetBeans releases in between IDE releases:
January
March
July?
September
4 releases of VSNetBeans. And there can be patch release if necessary to fix something really broken in VSIX.
Martin
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Neil C Smith <ne...@apache.org>.
On Mon, 3 Feb 2025 at 18:15, Matthias Bläsing
<mb...@doppel-helix.eu.invalid> wrote:
> I think we are heavily overcomplicating things. We had a phase where we
> wanted to do timebased releases. Given this whole discussion, I think
> it would be the right moment to revisit that idea.
To be replaced with what? I'm curious what you might have in mind,
because most changes that have been suggested in the past would likely
lead to higher release workload.
> This also raises the question why NetBeans IDE needs a multi RC phase,
> while NBCode does not.
The IDE and platform releases are massively more complex to prepare,
not to mention still difficult to push updates to. A pulled vote
there is throwing away hours of work (not to mention resources and
bandwidth). The RCs are cheap to produce. Getting testing and fixing
done before going to a vote is far more important for the IDE and
platform than the single VSNetBeans artefact.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Matthias Bläsing <mb...@doppel-helix.eu.INVALID>.
Hi,
I think we are heavily overcomplicating things. We had a phase where we
wanted to do timebased releases. Given this whole discussion, I think
it would be the right moment to revisit that idea.
Lets consider NBCode would do the same as NetBeans IDE, then we would
at times have to "delivery" branches, which get fixes independend from
each other. At the end the two flavors would have a different bugfix
level, as currently merges are delivery->master only, and thus fixes
never reach a secondary release branch.
This also raises the question why NetBeans IDE needs a multi RC phase,
while NBCode does not.
While I'm not interested in NBCode or the whole "OCI" thing, I don't
see value in splitting repos or issues. Of course there are issues
specific to NBCode and NetBeans IDE, but the core parts are shared and
so apart from two places to look for I see little value.
Greetings
Matthias
Am Freitag, dem 31.01.2025 um 16:31 +0000 schrieb Neil C Smith:
> On Fri, 31 Jan 2025 at 16:05, Martin Balin <mb...@apache.org> wrote:
> > I’m asking this as using same date for NetBeans IDE and VSNetBeans branching (if these are close enough) was proposed earlier in this thread.
> ...
> > JDK releases are usually closer to 15th of the month therefore it will be better if VSNetBeans can branch ~ 10 days prior JDK days, from master, using vsnetBeans_xyz branch. (See proposed schedule below)
>
> And that proposal is still, IMO, how this should be done. Why not a
> change to the branch dates if you need it to be earlier, as was
> suggested? Having different branch dates too close together is going
> to be a problem for stability.
>
> > Therefore delivery and vsnetBeans_xyz branch will coexist in some time slots during the year.
>
> That was expected. As long as everything going into master goes via
> delivery, that's not a problem. If you're cherry picking commits to
> vsnetbeans(?), you could cherry pick from whichever branch you want.
>
> > (Version tbd)
>
> It would be good to use separate version numbers, and a separate
> branching repo with your own issue queue, milestones, etc. This is
> already a point of confusion.
>
> Personally I'd also like to see a hard limit on the number of
> VSNetBeans releases between IDE releases in case of release delays in
> future.
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Neil C Smith <ne...@apache.org>.
On Fri, 31 Jan 2025 at 16:05, Martin Balin <mb...@apache.org> wrote:
> I’m asking this as using same date for NetBeans IDE and VSNetBeans branching (if these are close enough) was proposed earlier in this thread.
...
> JDK releases are usually closer to 15th of the month therefore it will be better if VSNetBeans can branch ~ 10 days prior JDK days, from master, using vsnetBeans_xyz branch. (See proposed schedule below)
And that proposal is still, IMO, how this should be done. Why not a
change to the branch dates if you need it to be earlier, as was
suggested? Having different branch dates too close together is going
to be a problem for stability.
> Therefore delivery and vsnetBeans_xyz branch will coexist in some time slots during the year.
That was expected. As long as everything going into master goes via
delivery, that's not a problem. If you're cherry picking commits to
vsnetbeans(?), you could cherry pick from whichever branch you want.
> (Version tbd)
It would be good to use separate version numbers, and a separate
branching repo with your own issue queue, milestones, etc. This is
already a point of confusion.
Personally I'd also like to see a hard limit on the number of
VSNetBeans releases between IDE releases in case of release delays in
future.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Martin Balin <mb...@apache.org>.
Hi,
Thanks to all, we've released VSNetBeans 24.9.9 in January using partially the proposed process. It went well in my opinion, although not done really in parallel with active release250 & delivery branches.
I would like to continue the discussion and have some questions. Will do it as timeline summary
1. Jan 16th - I’ve created VSNetBeans_249 branch. I did it after Eric Barboni on Slack confirmed it is OK "I think it's ok. I've just removed delivery branch”
2. After building 2 vote candidates VSNetBeans released on 24.1. It took 9 days.
3. NetBeans 25 release_250 was created by Eric on 24.1. as announced on 17.1.
—
Question: Is it the problem if `delivery` branch coexist with other release branch which does not pick all commits from delivery?
On 16.1. delivery branch was there since release 24.0 so it was going to be rebased anyway.
Commits done to vsnetBeans_249 will not affect the ‘old' delivery. And if new delivery used for release_250 would be active then commits will go to delivery 1st and then to vsnetBeans_249 if this fix is the must for both. I don’t see there problems with git itself. Is this the process issue or GitHub issue??
I’m asking this as using same date for NetBeans IDE and VSNetBeans branching (if these are close enough) was proposed earlier in this thread. Therefore delivery and vsnetBeans_xyz branch will coexist in some time slots during the year.
JDK releases are usually closer to 15th of the month therefore it will be better if VSNetBeans can branch ~ 10 days prior JDK days, from master, using vsnetBeans_xyz branch. (See proposed schedule below)
—
4. Next VSNetBeans release will be 25.0 together with NetBeans 25.0 in Feb.
Proposed VSNetBeans schedule:
5. VSNetBeans 25.x.x branch around March 8th from master to match JDK release on March 18th. (Version tbd)
6. VSNetBeans 25.x.y branch around April 4th from master to match JDK release on April 15th. (If this needs to happen at all)
7. NetBeans 26 release_260 branch created on or slightly after 15.4. -> release both NetBeans IDE and VSNetBeans in May
8. … and so on...
What do you think?
Martin
> On 9. 1. 2025, at 19:32, Martin Balín <ma...@windowslive.com> wrote:
>
> Hi,
>
>> On 9. 1. 2025, at 11:11, Neil C Smith <ne...@apache.org> wrote:
>>
>> On Thu, 9 Jan 2025 at 09:20, Svata Dedic <sv...@gmail.com> wrote:
>>> On 05. 12. 24 16:20, Neil C Smith wrote:
>>>> That looks like it could work with a fixed monthly branch date, even
>>>> if not all get used. The important thing is to have a shared branch
>>>> date with the IDE in those months that need both. Or to keep the
>>>> branch dates far enough apart, but I can't see that working with that
>>>> schedule.
>>>
>>> Apologies, I got lost in the wording. Could you please give an example
>>> how do you think the branch + date coordination should work and what are
>>> the important coordination points/concepts from your point of view ?
>>
>> With the stabilization that goes in towards freeze and branch, trying
>> to do that for different dates within a week or two of each other will
>> be a nightmare. The notice emails that usually go out in the weeks
>> preceding freeze emphasise being "release aware". That's difficult to
>> achieve if working to different dates.
>>
>> So, I'm suggesting picking a date of each month on which branch can
>> happen, even if the IDE, or even both releases, don't use it.
>> Currently that would be around the 15th (rarely exactly 15th), but
>> that can be changed. We have a policy of keeping master in a
>> releasable state already. That would be particularly important
>> 7th-15th of every month.
> This sounds good.
>>
>> In the months that both the IDE and VSNetBeans projects branch, we
>> branch from the same commit on master, coordinated between release
>> managers. VSNetBeans release does not have to wait for the IDE to
>> release as now. The branch point is more of a concern than the
>> release date.
> So, applying above to upcoming NB 25 release schedule means. Release branch for NetBeans 25 on Jan 15th, or so and same commit used also for VSNetBeans 24.9 release.
> VSNetBeans 24.9 releases Jan 21st or soon after with upcoming JDK release dates.
> NetBeans 25 releases around Feb 15th.
> Martin
>>
>> Best wishes,
>>
>> Neil
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org <ma...@netbeans.apache.org>
> For additional commands, e-mail: dev-help@netbeans.apache.org <ma...@netbeans.apache.org>
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Martin Balín <ma...@windowslive.com>.
Hi,
> On 9. 1. 2025, at 11:11, Neil C Smith <ne...@apache.org> wrote:
>
> On Thu, 9 Jan 2025 at 09:20, Svata Dedic <sv...@gmail.com> wrote:
>> On 05. 12. 24 16:20, Neil C Smith wrote:
>>> That looks like it could work with a fixed monthly branch date, even
>>> if not all get used. The important thing is to have a shared branch
>>> date with the IDE in those months that need both. Or to keep the
>>> branch dates far enough apart, but I can't see that working with that
>>> schedule.
>>
>> Apologies, I got lost in the wording. Could you please give an example
>> how do you think the branch + date coordination should work and what are
>> the important coordination points/concepts from your point of view ?
>
> With the stabilization that goes in towards freeze and branch, trying
> to do that for different dates within a week or two of each other will
> be a nightmare. The notice emails that usually go out in the weeks
> preceding freeze emphasise being "release aware". That's difficult to
> achieve if working to different dates.
>
> So, I'm suggesting picking a date of each month on which branch can
> happen, even if the IDE, or even both releases, don't use it.
> Currently that would be around the 15th (rarely exactly 15th), but
> that can be changed. We have a policy of keeping master in a
> releasable state already. That would be particularly important
> 7th-15th of every month.
This sounds good.
>
> In the months that both the IDE and VSNetBeans projects branch, we
> branch from the same commit on master, coordinated between release
> managers. VSNetBeans release does not have to wait for the IDE to
> release as now. The branch point is more of a concern than the
> release date.
So, applying above to upcoming NB 25 release schedule means. Release branch for NetBeans 25 on Jan 15th, or so and same commit used also for VSNetBeans 24.9 release.
VSNetBeans 24.9 releases Jan 21st or soon after with upcoming JDK release dates.
NetBeans 25 releases around Feb 15th.
Martin
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 9 Jan 2025 at 09:20, Svata Dedic <sv...@gmail.com> wrote:
> On 05. 12. 24 16:20, Neil C Smith wrote:
> > That looks like it could work with a fixed monthly branch date, even
> > if not all get used. The important thing is to have a shared branch
> > date with the IDE in those months that need both. Or to keep the
> > branch dates far enough apart, but I can't see that working with that
> > schedule.
>
> Apologies, I got lost in the wording. Could you please give an example
> how do you think the branch + date coordination should work and what are
> the important coordination points/concepts from your point of view ?
With the stabilization that goes in towards freeze and branch, trying
to do that for different dates within a week or two of each other will
be a nightmare. The notice emails that usually go out in the weeks
preceding freeze emphasise being "release aware". That's difficult to
achieve if working to different dates.
So, I'm suggesting picking a date of each month on which branch can
happen, even if the IDE, or even both releases, don't use it.
Currently that would be around the 15th (rarely exactly 15th), but
that can be changed. We have a policy of keeping master in a
releasable state already. That would be particularly important
7th-15th of every month.
In the months that both the IDE and VSNetBeans projects branch, we
branch from the same commit on master, coordinated between release
managers. VSNetBeans release does not have to wait for the IDE to
release as now. The branch point is more of a concern than the
release date.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Svata Dedic <sv...@gmail.com>.
Hi,
sorry for late response,
On 05. 12. 24 16:20, Neil C Smith wrote:
> That looks like it could work with a fixed monthly branch date, even
> if not all get used. The important thing is to have a shared branch
> date with the IDE in those months that need both. Or to keep the
> branch dates far enough apart, but I can't see that working with that
> schedule.
Apologies, I got lost in the wording. Could you please give an example
how do you think the branch + date coordination should work and what are
the important coordination points/concepts from your point of view ?
Thanks !
-Svata
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 5 Dec 2024 at 14:51, Martin Balin <mb...@apache.org> wrote:
> Not monthly. VSCode plugin will release around JDK releases https://www.java.com/releases/ incl CPU.
> Java support released with JDK releases.
> As this is Java developer tool and VSCode extensions ecosystem is fast changing this works. Given short period of time between releases stabilization cycle can be short as well for module set included in VScode ext
That looks like it could work with a fixed monthly branch date, even
if not all get used. The important thing is to have a shared branch
date with the IDE in those months that need both. Or to keep the
branch dates far enough apart, but I can't see that working with that
schedule.
It's good to understand that aligning with JDK releases, including
CPU, is what is driving the thinking behind this. That still needs
agreeing to by the PMC and on this list though.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Martin Balin <mb...@apache.org>.
> On 12. 11. 2024, at 16:00, Michael Bien <mb...@gmail.com> wrote:
>
> On 12.11.24 15:40, Neil C Smith wrote:
>> On Tue, 12 Nov 2024 at 14:17, Michael Bien <mb...@gmail.com> wrote:
>>> 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.
>> Well, I don't think the distinction needs to be between branching from
>> the release and branching from master at random times.
>>
>> At present the IDE has a fairly specific branch point at ~15th of
>> every third month.
>>
>> Say if the VSCode plugin wanted to release monthly,
Not monthly. VSCode plugin will release around JDK releases https://www.java.com/releases/ incl CPU.
Java support released with JDK releases.
As this is Java developer tool and VSCode extensions ecosystem is fast changing this works. Given short period of time between releases stabilization cycle can be short as well for module set included in VScode ext
Martin
>
> this detail would be a key requirement for this discussion. Without knowing how frequent the releases are intended to be, it is very difficult to make suggestions since it influences the setup.
>
> Cherry-picks work ok for update releases which contain bug fixes and occasionally a feature.
>
> If we are talking about something which is closer to rolling releases, it would have to branch from master most likely.
>
> (I do not strongly oppose branching from master as already mentioned, but lets not release the equivalent of JDK 24ea build 1. Master is to be expected to be more stable when NB stabilizes)
>
> -mbien
Re: Apache NetBeans extension for Visual Studio Code
Posted by Michael Bien <mb...@gmail.com>.
On 12.11.24 15:40, Neil C Smith wrote:
> On Tue, 12 Nov 2024 at 14:17, Michael Bien <mb...@gmail.com> wrote:
>> 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.
> Well, I don't think the distinction needs to be between branching from
> the release and branching from master at random times.
>
> At present the IDE has a fairly specific branch point at ~15th of
> every third month.
>
> Say if the VSCode plugin wanted to release monthly,
this detail would be a key requirement for this discussion. Without
knowing how frequent the releases are intended to be, it is very
difficult to make suggestions since it influences the setup.
Cherry-picks work ok for update releases which contain bug fixes and
occasionally a feature.
If we are talking about something which is closer to rolling releases,
it would have to branch from master most likely.
(I do not strongly oppose branching from master as already mentioned,
but lets not release the equivalent of JDK 24ea build 1. Master is to be
expected to be more stable when NB stabilizes)
-mbien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Neil C Smith <ne...@apache.org>.
On Tue, 12 Nov 2024 at 14:17, Michael Bien <mb...@gmail.com> wrote:
> 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.
Well, I don't think the distinction needs to be between branching from
the release and branching from master at random times.
At present the IDE has a fairly specific branch point at ~15th of
every third month.
Say if the VSCode plugin wanted to release monthly, they could branch
at ~15th of every month. Every third month, the IDE and plugin branch
on the same date from the same point on master.
I would be concerned if we had random branching, particularly within a
week or two either side of the IDE release branching. That's a recipe
for chaos, and should probably not be allowed in any solution we
arrive at.
Branching on the same date does not mean the VSCode plugin has to wait
to release with the IDE. It can still stabilise and release quickly.
Decoupling release dates is potentially simpler than totally
decoupling branch points.
If ~15th in that scenario doesn't work for the VSCode plugin then we
could change the IDE branch date to be earlier or later in the month.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Michael Bien <mb...@gmail.com>.
On 12.11.24 14:52, Martin Balin wrote:
> Hi,
>
>> On 12. 11. 2024, at 13:11, Michael Bien <mb...@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 <mb...@gmail.com> wrote:
>>>
>>>> On 01.11.24 13:17, Martin Balín wrote:
>>>>>> On 30. 10. 2024, at 16:26, Neil C Smith <ne...@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-unsubscribe@netbeans.apache.org
>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Martin Balin <mb...@apache.org>.
Hi,
> On 12. 11. 2024, at 13:11, Michael Bien <mb...@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 <mb...@gmail.com> wrote:
>>
>>> On 01.11.24 13:17, Martin Balín wrote:
>>>>> On 30. 10. 2024, at 16:26, Neil C Smith <ne...@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-unsubscribe@netbeans.apache.org
>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Michael Bien <mb...@gmail.com>.
On 12.11.24 14:59, Neil C Smith wrote:
> On Tue, 12 Nov 2024 at 12:16, Michael Bien <mb...@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.
in that case -> all good.
-mbien
> 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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Neil C Smith <ne...@apache.org>.
On Tue, 12 Nov 2024 at 12:16, Michael Bien <mb...@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Michael Bien <mb...@gmail.com>.
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 are initially based on a
NB release tag but can cherry pick from apache/netbeans#master and
release as often as needed
- 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)
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
- 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 <mb...@gmail.com> wrote:
>
>> On 01.11.24 13:17, Martin Balín wrote:
>>>> On 30. 10. 2024, at 16:26, Neil C Smith <ne...@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-unsubscribe@netbeans.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Jan Lahoda <la...@gmail.com>.
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 <mb...@gmail.com> wrote:
> On 01.11.24 13:17, Martin Balín wrote:
> >
> >> On 30. 10. 2024, at 16:26, Neil C Smith <ne...@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-unsubscribe@netbeans.apache.org
> >> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: Apache NetBeans extension for Visual Studio Code
Posted by Michael Bien <mb...@gmail.com>.
On 10.11.24 13:35, Michael Bien wrote:
> On 01.11.24 13:17, Martin Balín wrote:
>>
>>> On 30. 10. 2024, at 16:26, Neil C Smith <ne...@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.
speaking of which... two additional PRs were just merged to delivery. So
this clearly isn't working already. Despite discussion thread, periodic
NOTICE threads and direct pings on github.
-mbien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Michael Bien <mb...@gmail.com>.
On 01.11.24 13:17, Martin Balín wrote:
>
>> On 30. 10. 2024, at 16:26, Neil C Smith <ne...@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-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache NetBeans extension for Visual Studio Code
Posted by Martin Balín <ma...@windowslive.com>.
Hi
> On 1. 11. 2024, at 14:15, Neil C Smith <ne...@apache.org> wrote:
>
> Hi,
>
> On Fri, 1 Nov 2024 at 12:17, Martin Balín <ma...@windowslive.com> wrote:
>> 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.
>
> It at least looks like the existing Jenkins job has been updated to
> build the binaries from the source zip now? That at least covers a
> part of why I suggested looking at the GH workflows, although they're
> more strongly segregated. I still think might be worth looking at
> moving over, as we have discussed for the IDE.
Yes, the job was updated and it builds currently what is officially used to build NetBeans and then VSNetBeans, no Rust. It was one time mistake.
>
> The other thing that should perhaps be looked at is ensuring the
> source bundle only contains the code required to build the VSCode
> plugin. Hopefully we won't accidentally release the Rust cluster
> again, but perhaps if releases are entirely separated a distinct
> cluster config for VSCode might be a good idea.
If VSNetBeans is separate product then it likely makes sense to release Source code artefact which corresponds to what is built into VSNetBeans. So it matches.
>
> Does VSNetBeans really need a metabuild file at all?
I don’t think it needs meta build file. If this is not a requirement then yes skip it.
> Releasing all
> modules with dev-GITHASH implementation versions ties up better with
> their status? Embedding versions that diverge from the IDE might end
> up causing confusion in future with logs, etc. Using a separate repo
> would at least give distinct issue queue and milestones, which might
> be necessary to reduce confusion with IDE releases.
>
>> 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.
>
> Yes, I know that. But I cannot remember a thread here where we
> mentioned caring about Micronaut releases for instance?! ;-)
I cannot remember it either. We care since Micronaut support was added ~3 years ago :-(
>
> I think there should be a documented process and criteria for
> releases, similar to how the IDE release schedule was written, that is
> agreed here by lazy consensus.
I agree. If this is the next step in our discussion here I can prepare it.
Martin
>
>> 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.
>
> Sure, we have no capacity problem in releases if we take out some of
> the major, key tasks of doing releases! :-)
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
Re: Apache NetBeans extension for Visual Studio Code
Posted by Neil C Smith <ne...@apache.org>.
Hi,
On Fri, 1 Nov 2024 at 12:17, Martin Balín <ma...@windowslive.com> wrote:
> 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.
It at least looks like the existing Jenkins job has been updated to
build the binaries from the source zip now? That at least covers a
part of why I suggested looking at the GH workflows, although they're
more strongly segregated. I still think might be worth looking at
moving over, as we have discussed for the IDE.
The other thing that should perhaps be looked at is ensuring the
source bundle only contains the code required to build the VSCode
plugin. Hopefully we won't accidentally release the Rust cluster
again, but perhaps if releases are entirely separated a distinct
cluster config for VSCode might be a good idea.
Does VSNetBeans really need a metabuild file at all? Releasing all
modules with dev-GITHASH implementation versions ties up better with
their status? Embedding versions that diverge from the IDE might end
up causing confusion in future with logs, etc. Using a separate repo
would at least give distinct issue queue and milestones, which might
be necessary to reduce confusion with IDE releases.
> 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.
Yes, I know that. But I cannot remember a thread here where we
mentioned caring about Micronaut releases for instance?! ;-)
I think there should be a documented process and criteria for
releases, similar to how the IDE release schedule was written, that is
agreed here by lazy consensus.
> 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.
Sure, we have no capacity problem in releases if we take out some of
the major, key tasks of doing releases! :-)
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists