docs: Release process script and documentation

[dcalhoun]

What?

Improve the release process.

Why?

So far, the process is manual and undocumented, making it difficult for others to contribute.

How?

Add and document a release script.

The trunk branch is used for simplicity while iOS builds are still manually created and committed. Long term, we should perform that with CI tasks and remove the ability for repository admins from pushing directly to origin/trunk.

Testing Instructions

Test the script. This is expected to throw an error due to not running on the trunk branch.

make release VERSION_TYPE=minor DRY_RUN=true

Accessibility Testing Instructions

N/A, no user-facing changes.

Screenshots or screencast

N/A, no user-facing changes.

[oguzkocer]

I skimmed through the changes and left a suggestion, but I am fine to merge it as is since it's still an improvement over a manual process.

Just for future reference, we have most of this already built in release-toolkit project, using fastlane. All apps are released with this process and it's constantly being improved by wordpress-mobile/apps-infrastructure team. It'd have been great to follow the same path or even make a request to their team to set up automated releases as they can do this type of thing relatively quickly. Now that it's already implemented this way, I don't want to block it, but I can see us removing it in not so distant future.

[oguzkocer]

If it's going to make commits, it probably shouldn't do it while we are on trunk. The way this is handled for app releases is that the scripts would create a release/x.y.z branch and make the changes there. The tag is also created from this branch. Once it's done, it'd create a PR against trunk.

[dcalhoun]

If it's going to make commits, it probably shouldn't do it while we are on trunk. The way this is handled for app releases is that the scripts would create a release/x.y.z branch and make the changes there. The tag is also created from this branch. Once it's done, it'd create a PR against trunk.

I agree. I consider the use of the trunk branch for this as a temporary solution—ideally, a short one—for avoiding PRs that create a large amount of noise due to the current VCS tracking of iOS build output.

This is what I attempted to convey in the PR description:

The trunk branch is used for simplicity while iOS builds are still manually created and committed. Long term, we should perform that with CI tasks and remove the ability for repository admins from pushing directly to origin/trunk.

[dcalhoun]

Just for future reference, we have most of this already built in release-toolkit project, using fastlane. All apps are released with this process and it's constantly being improved by wordpress-mobile/apps-infrastructure team. It'd have been great to follow the same path or even make a request to their team to set up automated releases as they can do this type of thing relatively quickly. Now that it's already implemented this way, I don't want to block it, but I can see us removing it in not so distant future.

Makes complete sense. I agree we should embrace existing tooling.

For context, my primary motivation for opening this PR was documenting the process so that I am not the only person with the knowledge. I then realized I could use an LLM to generate a script from my documentation very quickly. Hence, the script. 🙂

I'll merge this with the understanding it should be replaced sooner rather than later.