Allow extensions to conditionally register menu contributions based on VSCode version

[firelizzard18]

I want to add a menu contribution to testing/item/context (golang/vscode-go#1590). I also want to support VSCode 1.58 (golang/vscode-go#1688). I would like some way to indicate that the contribution to testing/item/context should be ignored by VSCode 1.58.

I can register the test controller conditionally on vscode.tests.createTestController being defined, but AFAIK I cannot conditionally contribute a menu.

[connor4312]

I think the recommended way for this would be to either:

• set engines.vscode to ^1.59.0, though that would prevent the extension from being installed wholesale on these old versions.
• use the setContext command to conditionally add a context key on certain product versions that is part of the when clause

I doubt we'd consider a generalized product version feature gate for contribution points

[firelizzard18]

@connor4312 The goal is to retain support for 1.58. When I tested it on 1.58, I got the following notification:

[golang.go]: testing/item/context is a proposed menu identifier and is only available when running out of dev or with the following command line switch: --enable-proposed-api golang.go

I had set a breakpoint in activate, which didn't get hit. If this error prevents the extension from activating, setContext won't work.

[hyangah]

• use the setContext command to conditionally add a context key on certain product versions that is part of the when clause

It looks like proposed api/valid api check is done without when check

• set engines.vscode to ^1.59.0, though that would prevent the extension from being installed wholesale on these old versions.

Some users of vscode-go extensions were affected by #130457 and chose to stay with 1.58. We can rely on the microsoft marketplace & vscode to suggest compatible versions to old vs code users temporarily and go forward to adopt 1.59 engine. However, if those users are locked in too long, I worry that it will prevent users of 1.58 from picking up critical bug fixes or other new features.

[connor4312]

Thanks for the info. I think introducing a productVersion context key and evaluating that before checking the proposed version makes sense, as APIs transition from proposed to stable. I'll let Alex weigh in on that.

[alexdima]

I hope you don't get too upset with me, but I will not work on this:

• Team considers maintaining split JSON settings editor is too much work
• Users decide they will stay on 1.58 in perpetuity and never upgrade anymore
• Extension decides to support 1.58 in perpetuity to support the users that don't want to upgrade anymore
• ...
• we need to implement a new solution to allow extensions to support in perpetuity old VS Code versions?

[firelizzard18]

@alexdima I think "in perpetuity" is hyperbole at this point, since we're only trying to support one version back. That being said, I am staying up to date, so my investment is purely in making my best reasonable effort to satisfy a user request.