Revert a mistake in v0.22 that prevents cargo publish (#1065)

#1055 removed the version for
`mmtk-macros` in `Cargo.toml`. I thought it was fine, as it uses a local
path as the dependency. But `cargo publish` actually requires all the
dependencies to specify a version. So `cargo publish` failed for
https://github.com/mmtk/mmtk-core/releases/tag/v0.22.0 in
https://github.com/mmtk/mmtk-core/actions/runs/7284255107/job/19849376243.
The action did not return a non-zero code so I was not aware of the
issue. `v0.22` was not published to `crates.io`.

This PR adds back the version for `mmtk-macros`, adds a check for `cargo
publish` dry run in the style check, and fixes the publish script so the
script properly fails if all the attempts of `cargo publish` fail.

Author: qinsoon

.github/scripts/ci-style.sh

@@ -42,3 +42,9 @@ style_check_auxiliary_crate() {
 }
 
 style_check_auxiliary_crate macros
+
+# --- cargo publish dry run ---
+# Main crate
+cargo publish --dry-run
+# Macros
+cargo publish --dry-run --manifest-path=macros/Cargo.toml

.github/workflows/cargo-publish.yml

@@ -33,9 +33,16 @@ jobs:
       # The script will retry publish for 5 times with 60 seconds between the retries.
       - name: Public mmtk-core
         run: |
+          success=false
+
           for n in {1..5}; do
-            echo "Attempt #"$n
-            cargo publish && break
-            echo "Wait for Retry #"$n
-            sleep 60
+              echo "Attempt #"$n
+              cargo publish && { success=true; break; }
+              echo "Wait for Retry #"$n
+              sleep 60
           done
+
+          if [ "$success" = false ]; then
+              echo "All attempts to publish failed."
+              exit 1
+          fi

Cargo.toml

@@ -37,8 +37,8 @@ libc = "0.2"
 log = { version = "0.4", features = ["max_level_trace", "release_max_level_off"] }
 memoffset = "0.9"
 mimalloc-sys = { version = "0.1.6", optional = true }
-# MMTk macros
-mmtk-macros = { path = "macros/" }
+# MMTk macros - we have to specify a version here in order to publish the crate, even though we use the dependency from a local path.
+mmtk-macros = { version="0.22.0", path = "macros/" }
 num_cpus = "1.8"
 num-traits = "0.2"
 pfm = { version = "0.1.1", optional = true }

docs/team/release.md

@@ -32,7 +32,7 @@ If the current version is `0.X.x`, the new version should be `0.X+1.0`.
 The PR should include these changes:
 
 1. Bump version in `Cargo.toml`.
-2. Bump version in `macros/Cargo.toml`.
+2. Bump version in `macros/Cargo.toml`. Use the new version for the `mmtk-macros` dependency in `Cargo.toml`.
 3. Update `CHANGELOG.md`:
    1. Add a section for the new version number and the cut-off date (when the PR is created)
    2. Add change logs for the release. The following shows one convenient way to do it. If there is a better way, we should adopt.
@@ -81,7 +81,13 @@ Once the PRs are merged, we can tag releases on Github.
 2. Keep an eye on the CI status for the latest commit in MMTk core.
 3. Do point release for fixing severe issues. Currently we normally do not need point releases. Normal bug fixes or any other issues can be fixed in the next release.
    But in rare cases, such as the current tagged release cannot build, cannot run, or it somehow fails in publishing, we may need to do a point release.
-   * If there is no other commit in `master` yet, doing a point release follows exactly the same process above. Depending on the changes, we may or may not need a point release
-     for the bindings.
-   * If there are commits in `master` that we do not want to include in the point release, the point release should be in a separate branch in the upstream repository.
-     The changes for the point release should be merged back to `master`.
+
+### Point release
+
+   1. Create a pull request to fix the issue.
+   2. Create a pull request to bump the version number, following the same process [above](#create-prs-to-bump-the-version-number).
+   3. Once the PRs are merged,
+      * Create a branch in the main repository based on the last release `v0.x.y` (from `master` or from the last point release branch), named with the new point release version, such as `v0.x.y+1`.
+      * Cherry pick commits from `master` that should be included in the new point release.
+      * Tag a release from the branch, following the same process [above](#tag-releases).
+      * If there is no other commit in `master` yet, there is no need to create a different branch for the release, and we can tag a release from `master`.