docs: track the newest containerisable Bitbucket version instead of a pin - #303
Merged
Merged
Conversation
… pin The 9.4.16 target had drifted. The container stack moved on while the config default, the auth status output, and the README still advertised 9.4.16, so the documented target described a version nothing was tested against. The intent was never to freeze on one release but to run the newest that works, and that has a real upper bound — newer releases have failed to run in this containerised stack, so the newest published release and the newest supportable one are not the same thing. Bumping the pin to the current stack version would only drift again at the next upgrade. So the version lives in one place: the image tag in docker/compose.yml and docker/custom-bitbucket/Dockerfile. Nothing else restates it. ADR 042 records this and supersedes ADR 018. BITBUCKET_VERSION_TARGET stays, so operators can record a version for their own environment, but it no longer defaults to one, and bb auth status reports it only when set. The field remains in the machine envelope: it is required by the bb.machine contract and removing it would break consumers. The API contract source is deliberately unchanged. The vendored 9.4 OpenAPI artifact pins the shapes the generated client is built from, which is spec provenance rather than a supported-version claim; the README now says so instead of leaving it ambiguous. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
9.4.16target had drifted. The container stack moved on while the config default, thebb auth statusoutput, and the README still advertised9.4.16— so the documented target described a version nothing was tested against.Bumping the pin to the current stack version would only drift again at the next upgrade, so this drops the claim instead.
The policy
Target the newest Bitbucket Data Center release that runs in the container stack and passes the live suite. That has a real upper bound — newer releases have failed to run in this stack — so the newest published release and the newest supportable one are not the same thing.
The version now lives in exactly one place: the image tag in
docker/compose.ymlanddocker/custom-bitbucket/Dockerfile. Nothing else restates it. Upgrading means bumping that image and letting the live suite decide.ADR 042 records this and supersedes ADR 018, using the repo's existing
superseded_bymechanism.Behaviour change
BITBUCKET_VERSION_TARGETstays, so operators can record a version for their own environment, but it no longer defaults to one.bb auth statusreports it only when set:bitbucket_version_targetremains in the machine envelope — it is a required field of thebb.machinecontract, so removing it would break consumers. It is simply empty unless set. Two tests cover both paths.Deliberately unchanged
The API contract source. The vendored
bitbucket-9.4-openapi.jsonpins the shapes the generated client is built from — that is spec provenance, not a supported-version claim, and changing it means a new spec plus client regeneration. The README now states this distinction instead of leaving it ambiguous.Verification
Build, vet and unit tests pass. The pre-push gate passed with the live suite running (patch coverage 100% on the earlier revision of this branch; exit 0 on the full gate).