Currently our `Makefile` and `bin/release` scripts are such that we effectively do the following when releasing:
```
publish:
for arch in [amd64 arm arm64]:
sub-publish:
clean_bin
publish
plugin_publish
```
which leads the Docker v2 plugin to contain `arm64` binaries even though we target `amd64`.
Swaping `publish` and `plugin_publish` is a simple way to avoid this.
"docker plugin" does not support tagging plugin images, therefore
we need to build plugin images two times - one for :latest and
for :$(WEAVE_VERSION).
Pushing of :latest happens only if $UPDATE_LATEST is not false.
Obtain the version and latest_release tag commit hashes before changing
into the cloned repository so that all tagging and pushing happens on
the outer repository.
The publish stage has been split into two pieces - a draft step that
creates a draft version release in Github and a publish step that
publishes the draft, updates `latest_release` and pushes images to
DockerHub.
It is also possible to specify `--pre-release` to draft. Once published
such a release will be marked with a prominent warning in GitHub;
additionally we do not update `latest_release` in GitHub nor push an
update to the `latest` tag in DockerHub.
To support arbitrarily named pre-releases we no longer impose any
restrictions on the format of the most recent annotated tag - instead we
expect to find a single annotated tag pointing at HEAD of the current
branch and assume this is the version to release.
We would like to have a stable URL for the most recently released
script, so that we can mention it in the README and people can use it
in update scripts.
Since GitHub's releases/latest URL redirects, and anyway doesn't work
for downloads, we have to create (possibly delete first) a release
tagged "latest_release" and update it.
Before, this could fail without a message if there was a changelog but
no matching line.
Also change the changelog format
== Release v0.0.1
to
== Release 0.0.1
Marc CARRE