Skip to content

Commit 391d9d9

Browse files
authored
Docs: Add release docs (#1392)
1 parent e45c668 commit 391d9d9

File tree

4 files changed

+92
-1
lines changed

4 files changed

+92
-1
lines changed

README.md

+5-1
Original file line numberDiff line numberDiff line change
@@ -13,7 +13,11 @@ You can test out the plugin (settings) with [WordPress Playground](https://wordp
1313
1414
## Documentation
1515

16-
WIP.
16+
- [Developer Documentation](docs/developer-docs.md) - Guide for developers working with the plugin.
17+
- [Development Environment](docs/development-environment.md) - Setting up your development environment.
18+
- [Pull Request Guidelines](docs/pull-request.md) - How to submit pull requests.
19+
- [Release Process](docs/release-process.md) - Guide for releasing new versions.
20+
- [Translations](docs/translations.md) - Information about translating the plugin.
1721

1822
## Federation
1923

docs/images/release-ui-major.png

1.24 MB
Loading

docs/images/release-ui-patch.png

1010 KB
Loading

docs/release-process.md

+87
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,87 @@
1+
# Release Process
2+
3+
This document outlines the process for creating new releases of the WordPress ActivityPub plugin. The process differs slightly between major/minor releases and patch releases.
4+
5+
## Major and Minor Releases
6+
7+
Major and minor releases follow the same release process. These releases are created from the `trunk` branch.
8+
9+
### Steps
10+
11+
1. **Generate Version Bump PR**
12+
- Use the release script to automatically generate a version bump pull request:
13+
```bash
14+
# From the plugin root directory
15+
npm run release
16+
```
17+
- The script will:
18+
- Prompt for the new version number
19+
- Update version numbers in relevant files
20+
- Update the changelog
21+
- Create a new branch
22+
- Commit changes
23+
- Push to GitHub
24+
- Create a pull request
25+
26+
2. **Review and Merge**
27+
- Review the generated PR to ensure all version numbers and changelog entries are correct.
28+
- Once approved, merge the PR into `trunk`.
29+
30+
3. **Create Release**
31+
- On GitHub, navigate to the main page of the repository.
32+
- To the right of the list of files, click **Releases**.
33+
- At the top of the page, click **Draft a new release**.
34+
- To choose a tag for the release, select the **Choose a tag** dropdown menu.
35+
- Type the version number for your release, then click **Create new tag**.
36+
- Select the **Target** dropdown menu, then click `trunk`.
37+
- Select the **Previous tag** dropdown menu, then click the tag that identifies the previous release.
38+
- Above the description field, click **Generate release notes**.
39+
- If you're ready to publicize your release, click **Publish release**.
40+
![Major/minor release UI](images/release-ui-major.png)
41+
42+
## Patch Releases
43+
44+
Patch releases require a more manual process as they need to be created from the previous release branch.
45+
46+
### Steps
47+
48+
1. **Restore Release Branch**
49+
- Locate the most recent release branch (for `5.3.0` it was [#1371](https://github.com/Automattic/wordpress-activitypub/pull/1371)).
50+
- If needed, recreate the branch from the last release tag.
51+
52+
2. **Create Version PR**
53+
- Base the version PR on PR [#1192](https://github.com/Automattic/wordpress-activitypub/pull/1192).
54+
- The release script doesn't support releasing patch versions, so you'll need to manually update version numbers and changelog entries.
55+
- Manually update version numbers in relevant files.
56+
- Manually update changelog and readme.txt with the patch version number above the entries that will be part of the release.
57+
58+
3. **Cherry-pick Changes**
59+
- Identify merge commits from `trunk` that need to be included.
60+
- Cherry-pick each merge commit into the release branch:
61+
```bash
62+
# Checkout the release branch.
63+
git checkout release/5.3.0
64+
65+
# Cherry-pick a merge commit.
66+
git cherry-pick -m 1 <commit-hash>
67+
```
68+
> Note: The `-m 1` flag is required when cherry-picking merge commits. Merge commits have two parent commits - the first parent (`-m 1`) is the target branch of the original merge (usually the main branch), and the second parent (`-m 2`) is the source branch that was being merged. We use `-m 1` to tell Git to use the changes as they appeared in the main branch.
69+
70+
4. **Resolve Conflicts**
71+
- Common conflict areas:
72+
- `CHANGELOG.md`
73+
- `readme.txt`
74+
- Resolve conflicts maintaining chronological order in changelog.
75+
- Ensure version numbers are correct.
76+
77+
5. **Create Release**
78+
- On GitHub, navigate to the main page of the repository.
79+
- To the right of the list of files, click **Releases**.
80+
- At the top of the page, click **Draft a new release**.
81+
- To choose a tag for the release, select the **Choose a tag** dropdown menu.
82+
- Type the version number for your release, then click **Create new tag**.
83+
- Select the **Target** dropdown menu, then click the branch that contains the patches you want to release.
84+
- Select the **Previous tag** dropdown menu, then click the tag that identifies the previous release.
85+
- Above the description field, click **Generate release notes**.
86+
- If you're ready to publicize your release, click **Publish release**.
87+
![Patch release UI](images/release-ui-patch.png)

0 commit comments

Comments
 (0)