|
| 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