c1d1df839 chore: package released binaries by architecture
Previously when we performed a release, we would do a Github Release for each binary in a particular
selection. Now, the approach is to have a single Github Release for all the binaries. The assets for
the single release will be a collection of zip files containing all nine binaries for each target
architecture.
The new release process stipulates that each package name should contain the version YYYY.MM.X.Y,
where X is the number of the current release cycle, and Y is a counter within the cycle, which
will be incremented for each RC build that is required.
To support these requirements, a package-arch target is added. It produces packages in the form,
e.g., 2024.07.1.1.autonomi.aarch64-unknown-linux-musl.zip. The release cycle numbers are provided
from a new file at the root of the repository. Those numbers should be updated or reset in a release
commit. The target either reads the version number from a PACKAGE_VERSION environment variable or
it will build it. The environment variable will be used in the release process, because the package
version will be required in multiple places.
The new process retains the upload of individual binaries to S3, so those packaging and upload
targets are retained, but they are renamed to package-bin and upload-packaged-bin-to-s3, to
distinguish them from the architecture packages.
The upload-github-release-assets target is completely removed because it was uploading the
individual binaries to their respective Github Releases, which is no longer relevant. The release
workflow will be updated accordingly, but not in this commit.
For testing the new targets, this commit only updates the simpler 'build and package release
artifacts' workflow; a subsequent commit will update the full release workflow.
15096c1bb chore: implement new process in release workflow
The release workflow is changed to implement the new release process, as it's defined in our RFC.
The workflow will be triggered manually, but jobs will only run if the branch being used is either
stable, or it has an rc prefix. This is so we can have complete control over when to push the
release out, because it may need to be coordinated with other things, like community announcements.
We now define four jobs:
build
runs for either stable or RC release
builds binaries for the seven supported architectures
s3-release
runs for either stable or RC release
packages individual binaries and uploads them to S3
runs after build job
github-release
runs for either stable or RC release
packages binaries per-architecture and creates a Github Release with the packages as assets
on an RC release the Github Release will be a pre-release
runs after build job
publish-crates
only runs for a stable release
use release-plz to publish crates and produce crate tags
runs after s3-release job
After the build job completes, s3-release and github-release do not depend on each other, so
they will run in parallel. The publish-crates job will wait for the completion of s3-release
(the reason is explained in a comment in the workflow, which I won't repeat here).
Now that release-plz is only used for publishing crates and tagging, we don't need to configure it
on a per-crate basis, so the configuration file is now very minimal.
1c3d037bd chore: script to bump versions for release candidate
Use this script at the beginning of a release candidate cycle to bump crates to their new versions.
Initially, the release-plz tool is used, detecting changes and bumping each crate accordingly,
which should cover breaking changes (if they have been correctly specified with the rules from the
conventional commits specification). For each crate not bumped by release-plz, a 'safety' bump
increments the PATCH version of that crate. In both cases, the -rc.1 pre-release specifier is
applied to the versions used.
The reason for the safety bump is to guarantee unique binary versions for each release cycle. If we
didn't bump, we could end up with binaries with the same version number as the previous stable
release. This could be the case even though the dependencies of the binary had been updated, which
would cause it to have different content from the previously released version. It is not ideal to
bump crates with no real material changes, but doing it this way is easier to manage.
Also remove previous version bumping scripts we don't need any more.
a1ffd4416 chore: provide utils for release candidate post
A markdown file provides a template that can be used for a post on Discourse for discussing the
current release candidate. There is also a Python script which gets a list of the closed PRs between
now and the last release. Some of the output from this can be used in the template.
Also provide a script for getting the current versions of crates and binaries. This can be handy if
you lost the output from the bump script.
c1d1df839 chore: package released binaries by architecture
Previously when we performed a release, we would do a Github Release for each binary in a particular selection. Now, the approach is to have a single Github Release for all the binaries. The assets for the single release will be a collection of zip files containing all nine binaries for each target architecture.
The new release process stipulates that each package name should contain the version
YYYY.MM.X.Y, whereXis the number of the current release cycle, andYis a counter within the cycle, which will be incremented for each RC build that is required.To support these requirements, a
package-archtarget is added. It produces packages in the form, e.g.,2024.07.1.1.autonomi.aarch64-unknown-linux-musl.zip. The release cycle numbers are provided from a new file at the root of the repository. Those numbers should be updated or reset in a release commit. The target either reads the version number from aPACKAGE_VERSIONenvironment variable or it will build it. The environment variable will be used in the release process, because the package version will be required in multiple places.The new process retains the upload of individual binaries to S3, so those packaging and upload targets are retained, but they are renamed to
package-binandupload-packaged-bin-to-s3, to distinguish them from the architecture packages.The
upload-github-release-assetstarget is completely removed because it was uploading the individual binaries to their respective Github Releases, which is no longer relevant. The release workflow will be updated accordingly, but not in this commit.For testing the new targets, this commit only updates the simpler 'build and package release artifacts' workflow; a subsequent commit will update the full release workflow.
15096c1bb chore: implement new process in release workflow
The release workflow is changed to implement the new release process, as it's defined in our RFC.
The workflow will be triggered manually, but jobs will only run if the branch being used is either
stable, or it has anrcprefix. This is so we can have complete control over when to push the release out, because it may need to be coordinated with other things, like community announcements.We now define four jobs:
release-plzto publish crates and produce crate tagsAfter the
buildjob completes,s3-releaseandgithub-releasedo not depend on each other, so they will run in parallel. Thepublish-cratesjob will wait for the completion ofs3-release(the reason is explained in a comment in the workflow, which I won't repeat here).Now that
release-plzis only used for publishing crates and tagging, we don't need to configure it on a per-crate basis, so the configuration file is now very minimal.1c3d037bd chore: script to bump versions for release candidate
Use this script at the beginning of a release candidate cycle to bump crates to their new versions.
Initially, the
release-plztool is used, detecting changes and bumping each crate accordingly, which should cover breaking changes (if they have been correctly specified with the rules from the conventional commits specification). For each crate not bumped byrelease-plz, a 'safety' bump increments thePATCHversion of that crate. In both cases, the-rc.1pre-release specifier is applied to the versions used.The reason for the safety bump is to guarantee unique binary versions for each release cycle. If we didn't bump, we could end up with binaries with the same version number as the previous stable release. This could be the case even though the dependencies of the binary had been updated, which would cause it to have different content from the previously released version. It is not ideal to bump crates with no real material changes, but doing it this way is easier to manage.
Also remove previous version bumping scripts we don't need any more.
a1ffd4416 chore: provide utils for release candidate post
A markdown file provides a template that can be used for a post on Discourse for discussing the current release candidate. There is also a Python script which gets a list of the closed PRs between now and the last release. Some of the output from this can be used in the template.
Also provide a script for getting the current versions of crates and binaries. This can be handy if you lost the output from the bump script.