Skip to content

Commit f49dec0

Browse files
authored
Merge pull request #151 from octoenergy/docs-backporting
Add release documentation for backporting bug fixes
2 parents 6e56b94 + 248bf58 commit f49dec0

File tree

1 file changed

+32
-0
lines changed

1 file changed

+32
-0
lines changed

docs/xocto/development.md

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -83,3 +83,35 @@ make tag
8383
```
8484

8585
This will trigger a Github action to publish the package to PyPI.
86+
87+
### Backporting a fix
88+
89+
If you've committed a bug fix that you'd like to release as a patch to a previous
90+
version (say, we've moved from 1.0.0 to 1.2.0 but you'd like to release a 1.0.1),
91+
then you can follow this recipe:
92+
93+
1. Checkout the tag of the version you want to backport to:
94+
95+
```sh
96+
git checkout v1.0.0
97+
```
98+
99+
2. Then cherry-pick the specific commit you want to backport:
100+
101+
```sh
102+
git cherry-pick <commit-hash>
103+
```
104+
105+
3. Next, follow the release process as defined above. Add the release note, bump
106+
the version to v1.0.1, and push the tag.
107+
108+
4. Repeat the process for any other versions you want to backport to, such as
109+
v1.1.0, ensuring that the changelog is updated to reflect v1.0.1 in each
110+
version you're updating.
111+
112+
5. Finally, update the changelog on `main` to reflect the newly backported versions.
113+
114+
Backporting should be used sparingly, as it can result in a non-linear change
115+
history as release tags diverge. Only critical bug fixes should be backported,
116+
and usually only when a new major version with backward compatible changes has
117+
been released inbetween the fix and backport target.

0 commit comments

Comments
 (0)