Skip to content

Commit 84712ca

Browse files
Improve text about avoiding forks (#870)
Signed-off-by: David A. Wheeler <[email protected]>
1 parent 0570e7c commit 84712ca

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

docs/Simplifying-Software-Component-Updates.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -58,7 +58,7 @@ Consider the following when developing and maintaining software with dependencie
5858
7. **For system applications and libraries, build on the oldest platform you want to support**. For more information see [[Delorie2019](https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility)].
5959
8. **If upgrading to a newer version of a component is impractical, backport vulnerability fixes to older versions**. Such backports can be done downstream or in a stable (LTS) branch maintained by the project. If the project does not maintain a stable release branch, but that component is so critically important to a user to backport vulnerability fixes downstream, consider contributing those backports upstream and/or offering support in maintaining such a stable release branch.
6060
9. **Favor using open source components from (distribution) providers which maintain stable releases of older components**.
61-
10. **Strive to avoid maintaining downstream modifications of open source code**. Downstream modifications may be pursued by users for various different reasons (e.g. business or use case specific features). However, maintaining such downstream modifications create a serious risk of accumulating changes over time which significantly hinder uplifting in a timely and seamless manner, due to the need to adapt those changes to every new upstream release. Instead, if changes are needed, e.g., new features, consider contributing or jointly developing those with the upstream project.
61+
10. **Avoid maintaining downstream modifications of open source code**. Downstream modifications may be pursued by users for various different reasons (e.g. business or use case specific features). However, maintaining such downstream modifications (aka a "project fork") typically accumulates changes over time. This creates a large risk of being unable to update the downstream version in a timely and seamless manner. The problem is that the downstream version must be adapted on every new upstream release. Instead, if changes like new features are needed, consider contributing or jointly developing those changes with the upstream project.
6262

6363
## Related Materials
6464

0 commit comments

Comments
 (0)