🏷️ Explain release process with manual tagging

[KYovchevski]

After brief talk with Jasper about intended push access for our repos, the conclusion reached is that the actual expected release strategy is to:

• push the release commit to a new branch while using --allow-branch
• PR the new release
• Manually create a tag once the PR has been merged

And then continue the process same as we've done until now. Essentially, we have the release go through a PR and tag it ourselves instead of letting cargo-release do that.

[MarijnS95]

Yup, pushing tags (and the bump commit straight via main) doesn't work. The problem was always:

1. Make a release and PR that
2. Accept and merge to main
3. Now we do not have access to push the tag on the just merged main commit, nor have the required CI process in place to auto-tag it.

[MarijnS95]

1. meaning new releases need to go into main through a PR
2. needs to PR the changes made due to the release

One sentence that says the same thing twice.

[MarijnS95]

Suggested change

	Once this is merged, the developer then needs to manually create a new tag for the release .
	Once this is merged, the developer then needs to manually create a new tag for the release.

We typically don't have rights for this either, AFAIK.

[KYovchevski]

Now we do not have access to push the tag on the just merged main commit, nor have the required CI process in place to auto-tag it.

So we cannot push a tag to main either? How do we do releases then?

[MarijnS95]

To be extra pedantic, there's no such thing as "push a tag to main". Both a tag and branch are "just" a reference to a commit.

It's the "repository" or "upstream" that you push something to.

In my experience, whenever I didn't have permission to push commits to main (updating the commit that main points to), I also didn't have permissions to push new tags (since tags are more or less "atomic", you're not expected to update them after they've been pushed, but that's an irrelevant detail here).

[KYovchevski]

To be extra pedantic, there's no such thing as "push a tag to main". Both a tag and branch are "just" a reference to a commit.

It's the "repository" or "upstream" that you push something to.

In my experience, whenever I didn't have permission to push commits to main (updating the commit that main points to), I also didn't have permissions to push new tags (since tags are more or less "atomic", you're not expected to update them after they've been pushed, but that's an irrelevant detail here).

Sorry, bad wording on my part.

The question still remains though, if we cannot push tags either, what is the supposed release workflow? I can see some of our repos are getting release tags and Github releases, such as intel-tex-rs-2, which would mean we can still do it, unless those just happen to have unprotected main

[MarijnS95]

@KYovchevski what I once wanted was (approximately) this:

1. Run cargo release to bump versions in various files;
2. Commit and push into PR (user action);
3. PR is merged;
4. CI picks up the Cargo.toml version = "" change;
5. CI pushes the tag;
6. CI pushes crate release to crates.io (could be the same job based on Cargo.toml changes, or triggered by the tag push).

That would also solve the permission step, but I just never automated step 4. yet.

In some crates however, we "kind of" automate 4./6. by always running cargo publish (on tag pushes) and crates.io will just reject it if that version already exists.

Note also that I've been migrating repositories to crates.io Trusted Publishing.