If a user has already set `compatibility_level`, it should be
incremented when a major release occurs.

We have package registry now!

We allow multiple usages of the plugin so that the `MODULE.bazel` can
be updated and then the `source.json` be created.

Running `buildozer` a second time will result in a exit code of 3.

We can make a valid assumption that if the version is _already_ the version
that is expected, then we do not need to update.

The capture group was too greedy and would leak through to
`bazel_dep(version = "...")` statements.

Modern Bazel module fetches now fetch the `metadata.json` file to determine the versions available.

We need to generate this and attach it to the release of the project.

Semrel

See merge request !3

`gitlab.arm.com` does not currently support the package registry.

It should be turned on Soon™

`@semantic-release/gitlab` does not support templating on the path, [yet].

[yet]: https://github.com/semantic-release/gitlab/pull/630

docs(dep5): fix project name

See merge request !2

Prepare for OSS release

See merge request !1

The old instructions pointed to the wrong GitLab instance and
also relied on the package registry, which isn't currently enabled
on this one.

This was accidentally removed in a previous commit.

Some dependencies were outdated or aren't currently available
publicly, and so these have been fixed.

Matthew Clarkson authored Apr 12, 2023 and Joshua Leivers committed Oct 11, 2023

This prevents having to do a breaking change of the project.

Previously, the usage was that the integrity of the `git archive`
output was used to match up the dynamically generated source archive
that GitLab (or GitHub) produces.

If we _require_, `archive` then those flows will break.

However, we can easily still support them by writing out to a
placeholder `src.tar` archive.

The documentation has been updated to push people towards providing an
`archive` keyword.