Bitbucket Versions¶
bb works with Bitbucket Data Center 9.2 and every release after it. A release
stays supported after Atlassian ends its support; it is only no longer tested.
The newest release, 10.5.1, is tested on every pull request.
The others in the window, 9.3.2, 9.4.24, 9.5.2, 9.6.5, 10.0.2, 10.1.5, 10.2.7, 10.3.2 and 10.4.3, are verified by
hand, by running the same suite against a real instance of each with
task test:live:matrix. Each one last passed:
| Release | Last passed | At commit |
|---|---|---|
| 9.3.2 | 2026-10-21 | 0c5bc25a026b |
| 9.4.24 | 2026-10-21 | 0c5bc25a026b |
| 9.5.2 | 2026-10-22 | 0c5bc25a026b |
| 9.6.5 | 2026-10-22 | 0c5bc25a026b |
| 10.0.2 | 2026-10-22 | 0c5bc25a026b |
| 10.1.5 | 2026-10-22 | 0c5bc25a026b |
| 10.2.7 | 2026-10-22 | 0c5bc25a026b |
| 10.3.2 | 2026-10-22 | 0c5bc25a026b |
| 10.4.3 | 2026-10-22 | 0c5bc25a026b |
Where an older release differs¶
bb is built against the newest release, and an older one behaves the same
except in the places below. In each, bb either answers the way the newest
release would, or refuses before sending anything, with the error kind
unsupported and exit code 14, naming the release that can do it. A dry run
gives the same answer as its verdict: the run would fail, as unsupported.
| Capability | From | On an earlier release |
|---|---|---|
A required build that spares pull requests or applies to the merge queue: requiredForPullRequest: false or requiredForMergeQueue: true in bb build required create or update |
10.2 | Refused. Bitbucket would store the check and ignore both fields, so it would block every pull request. A check reads back as applying to pull requests and not to a merge queue, which that release does not have. |
A required build or default reviewer condition matching the default branch: a DEFAULT_BRANCH ref matcher in bb build required create or update, or in bb reviewer condition create or update |
10.2 | Refused. Bitbucket refuses the required build and fails on the condition with a server error. |
A default reviewer condition naming reviewer groups: reviewerGroups in bb reviewer condition create or update |
9.5 | Refused. Bitbucket would store the condition without the groups. |
A default reviewer condition required to name reviewers or reviewer groups, in bb reviewer condition create or update |
9.5 | A condition naming no reviewers is stored if it requires at least one approval, and refused if it requires none. A reviewer named without an id is refused as invalid rather than not found. A dry run predicts what that release does. |
A no-creates branch restriction: --type no-creates on bb branch restriction and bb project branch-restriction |
9.4 | create and update are refused. list --type no-creates answers with none, which is what that release holds. |
A build status naming its repository: repository in what bb --json build get <commit> --key <key> --repo <project>/<slug> prints |
9.4 | bb names the repository the status was read through, as a later release does. |
Checking a release yourself¶
The live suite runs against any release the stack can start:
task test:live RELEASE=9.4.24
It starts an instance of that release beside the one already running, and a test whose behaviour differs by release checks the side that applies.
task test:live:matrix does the same for the oldest release tested and the
newest, which is where a difference shows, and
task test:live:matrix RELEASES=all for every release tested. Either way it
writes which of them passed to .tmp/.