Bump minor feature versions for mirror/keyserver-updated manifests

[Copilot]

This PR applies the semver minor version bumps for all features modified by the mirror/keyserver support work from devcontainers#1620. It updates only the version field in each affected src/*/devcontainer-feature.json manifest.

• Manifest version bumps (minor)

  • src/docker-in-docker/devcontainer-feature.json: 2.16.1 → 2.17.0
  • src/dotnet/devcontainer-feature.json: 2.5.0 → 2.6.0
  • src/github-cli/devcontainer-feature.json: 1.1.0 → 1.2.0
  • src/go/devcontainer-feature.json: 1.3.3 → 1.4.0
  • src/java/devcontainer-feature.json: 1.8.0 → 1.9.0
  • src/kubectl-helm-minikube/devcontainer-feature.json: 1.3.1 → 1.4.0
  • src/node/devcontainer-feature.json: 1.7.1 → 1.8.0
  • src/nvidia-cuda/devcontainer-feature.json: 3.0.0 → 3.1.0
  • src/php/devcontainer-feature.json: 1.1.4 → 1.2.0
  • src/powershell/devcontainer-feature.json: 2.0.2 → 2.1.0
  • src/python/devcontainer-feature.json: 1.8.0 → 1.9.0
  • src/ruby/devcontainer-feature.json: 1.3.2 → 1.4.0
  • src/rust/devcontainer-feature.json: 1.5.0 → 1.6.0
  • src/terraform/devcontainer-feature.json: 1.4.2 → 1.5.0

• Scope

  • No option/schema/script changes.
  • No formatting or structural manifest edits beyond the version line.

{
  "id": "go",
  "version": "1.4.0"
}

Original prompt

Create a pull request in repository bbartels/features against branch main that bumps the feature versions for all features modified by the existing mirror/keyserver support work reflected in PR devcontainers#1620.

Update the version field in each affected src/*/devcontainer-feature.json file using a semver minor bump (x.y.z -> x.(y+1).0).

Affected features and required target versions:

• src/docker-in-docker/devcontainer-feature.json: 2.16.1 -> 2.17.0
• src/dotnet/devcontainer-feature.json: 2.5.0 -> 2.6.0
• src/github-cli/devcontainer-feature.json: 1.1.0 -> 1.2.0
• src/go/devcontainer-feature.json: 1.3.3 -> 1.4.0
• src/java/devcontainer-feature.json: 1.8.0 -> 1.9.0
• src/kubectl-helm-minikube/devcontainer-feature.json: 1.3.1 -> 1.4.0
• src/node/devcontainer-feature.json: 1.7.1 -> 1.8.0
• src/nvidia-cuda/devcontainer-feature.json: 3.0.0 -> 3.1.0
• src/php/devcontainer-feature.json: 1.1.4 -> 1.2.0
• src/powershell/devcontainer-feature.json: 2.0.2 -> 2.1.0
• src/python/devcontainer-feature.json: 1.8.0 -> 1.9.0
• src/ruby/devcontainer-feature.json: 1.3.2 -> 1.4.0
• src/rust/devcontainer-feature.json: 1.5.0 -> 1.6.0
• src/terraform/devcontainer-feature.json: 1.4.2 -> 1.5.0

Requirements:

• Only change the version field in each listed feature manifest unless another mechanical update is strictly required by repository tooling.
• Preserve formatting as much as possible.
• Create a pull request back to bbartels/features:main with a concise title describing the minor version bumps for the changed features.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Bump the version of the feature you changed according to semver. i presumably need to do this for all the features i have changed for my pr in @devcontainers/featuresdevcontainers/pull/1620

Assistant: Yes — for this PR, you should bump the version for each feature whose shipped behavior changed, which in your case looks like all 14 touched features.

Since these changes add new mirror/keyserver override capabilities without obviously removing existing options, the safe/default semver interpretation is minor bumps (x.Y.z -> x.(Y+1).0) for each affected feature.

That gives you:

• docker-in-docker: 2.16.1 → 2.17.0
• dotnet: 2.5.0 → 2.6.0
• github-cli: 1.1.0 → 1.2.0
• go: 1.3.3 → 1.4.0
• java: 1.8.0 → 1.9.0
• kubectl-helm-minikube: 1.3.1 → 1.4.0
• node: 1.7.1 → 1.8.0
• nvidia-cuda: 3.0.0 → 3.1.0
• php: 1.1.4 → 1.2.0
• powershell: 2.0.2 → 2.1.0
• python: 1.8.0 → 1.9.0
• ruby: 1.3.2 → 1.4.0
• rust: 1.5.0 → 1.6.0
• terraform: 1.4.2 → 1.5.0

Why minor, not patch:

• you added new configurable behavior via env vars / mirror support
• most changes appear backward compatible
• patch is usually better for bug fixes with no user-visible capability expansion
• major would only make sense if behavior became incompatible

One caveat: PowerShell is the only one that might deserve extra scrutiny, because you changed version resolution behavior by removing the aka.ms/powershell-release redirect path and falling back to different metadata resolution. If maintainers view that as a breaking behavior change, they could ask for a major bump — but from what I can see, minor still seems reasonable.

If you want, I can next generate the exact edits you need for all 14 devcontainer-feature.json files.

User: for the powershell one, isn't it just a fallback? if aka.ms fails?

Assistant: Not as written — it’s not only a fallback if aka.ms fails.

From your diff, resolve_powershell_version() still starts by resolving a URL and extracting a version, but the PR description says you removed the aka.ms/powershell-release redirect-based version resolution path and now rely on the existing git-tag helpers / metadata path instead. So the important semver question is:

• if the normal version-resolution path for latest / lts / preview changed for all users, that’s a behavior change
• if you only added metadata.json as a backup when the first lookup returns nothing, that’s more like a patch-level resilience improvement

Based on the code shown, this specific block is definitely only a fallback:

if [ -z "${resolved_version}" ]; then
    # Fallback: fetch version from PowerShell metadata.json via GitHub
    ...
fi

So that block alone is patch-like.

But your PR description suggests there may also be a broader change in how the initial resolution works. If your final code path is still:

1. try the existing primary resolution path
2. only use metadata when that yields no version

then yes — I’d treat PowerShell as patch or at least argue patch is defensible.

If instead you replaced the old primary aka.ms mechanism entirely, then minor is still safer.

S...

This pull request was created from Copilot chat.