Skip to content

Commit 56548bc

Browse files
committed
docs: add docs on release process
1 parent 90186f4 commit 56548bc

File tree

2 files changed

+144
-0
lines changed

2 files changed

+144
-0
lines changed

.github/CONTRIBUTING.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
See [development.md](/docs/development.md) for more information.

docs/development.md

Lines changed: 143 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,143 @@
1+
# Development
2+
3+
This document outlines how to work with the project.
4+
5+
## Commit format
6+
7+
Our releases are automated and depend on commit messages to follow the
8+
Conventional Commits standard. You can read up on it here:
9+
https://www.conventionalcommits.org.
10+
11+
## Supported Minecraft versions
12+
13+
We only implement new features for the latest supported version of Minecraft.
14+
Our releases only ever support one version of Minecraft at a time. Even though
15+
it's technically possible to sometimes support multiple versions of Minecraft at
16+
the same time, for example when there've been no API changes, this adds a lot of
17+
complexity.
18+
19+
We do however fix bugs in older versions of Minecraft. There is no set rule for
20+
how many versions we support and it's up to the core maintainers' discression to
21+
decide what bugs are fixed.
22+
23+
## Branches and automatic releases
24+
25+
Releases in this repository are automated. Pushing to any of the following
26+
release branches triggers a build and release to Modrinth:
27+
- `main`
28+
- `mc/*` eg. `mc/1.21.3`. These branches are called "maintenance branches".
29+
30+
You cannot push directly to a release branch, but must instead raise a pull
31+
request. The pull request can either originate from a fork or from the
32+
repository itself. While external contributors are required to use forks,
33+
contributors with write access are encouraged to create branches in the
34+
repository for easier collaboration.
35+
36+
When creating a pull request towards a release branch our workflows will leave a
37+
comment on the PR indicating if the PR will trigger a release. There are also
38+
checks run to ensure your PR won't put the target branch in a broken state, for
39+
example by upgrading the Minecraft version of a maintenance branch.
40+
41+
> [!NOTE]
42+
> We only implement new features on the main release branch. Maintenance
43+
> branches only accept bug fixes, and pushing a feature or breaking change to
44+
> one will cause the release process to fail and require manually removing or
45+
> rewording the broken commit and force pushing.
46+
47+
When upgrading the mod to a newer version of Minecraft a maintenance branch must
48+
be created for the previous version. A PR that bumps the Minecraft version will
49+
be blocked from merging unless a maintenance branch has been created for the
50+
current version.
51+
52+
### Examples
53+
54+
<details>
55+
<summary>✨ Implementing a feature on the main branch</summary>
56+
57+
```sh
58+
# Checkout the main branch
59+
git checkout main
60+
git pull
61+
62+
# Create a feature branch
63+
git checkout -b my-cool-feature
64+
65+
# Implement your feature and push your changes
66+
git add -A
67+
git commit -m "feat: my cool feature"
68+
git push -u origin my-cool-feature
69+
70+
# Finally, create a pull request towards the main branch.
71+
# When merged, a new version will be released automatically.
72+
```
73+
</details>
74+
75+
<details>
76+
<summary>🐛 Fixing a bug for an older version of Minecraft</summary>
77+
78+
```sh
79+
# Checkout the maintenance branch
80+
git checkout mc/1.21.3
81+
git pull
82+
83+
# Create a branch for your fix
84+
git checkout -b my-fix
85+
86+
# Fix the bug and push your changes
87+
git add -A
88+
git commit -m "fix: did something"
89+
git push -u origin my-fix
90+
91+
# Finally, create a pull request towards the maintenance branch.
92+
# When merged, a new version will be released automatically.
93+
```
94+
</details>
95+
96+
<details>
97+
<summary>⬆️ Upgrading to a newer version of Minecraft</summary>
98+
99+
```sh
100+
# Checkout the main branch
101+
git checkout main
102+
git pull
103+
104+
# Create the maintenance branch. The name should match the
105+
# version of Minecraft currently supported on the main branch.
106+
git checkout -b mc/1.21.4
107+
git push -u origin mc/1.21.4
108+
109+
# Switch back to the main branch
110+
git checkout main
111+
112+
# Create a feature branch
113+
git checkout -b upgrade-to-mc-1.21.5
114+
115+
# Upgrade the Minecraft version and push your changes
116+
git add -A
117+
git commit -m "feat: Upgrade to Minecraft 1.21.5"
118+
git push -u origin upgrade-to-mc-1.21.5
119+
120+
# Finally, create a pull request towards the main branch.
121+
# When merged, a new version will be released automatically.
122+
```
123+
</details>
124+
125+
<details>
126+
<summary>📦 Grouping multiple changes into one release</summary>
127+
128+
Sometimes you may have multiple pull request that must be released together.
129+
This is easily done by creating an empty branch and targeting your other pull
130+
requests towards this branch. When you've merged all pull requests to the new
131+
branch, create a pull request for that branch as if it were any other feature
132+
branch.
133+
134+
```sh
135+
# Checkout the main branch
136+
git checkout main
137+
git pull
138+
139+
# Create and push an empty feature branch
140+
git checkout -b my-grouped-changes
141+
git push -u origin my-grouped-changes
142+
```
143+
</details>

0 commit comments

Comments
 (0)