Marco Ricci commited on 2025-01-19 13:12:54
Zeige 1 geänderte Dateien mit 4 Einfügungen und 4 Löschungen.
Change the phrasing of the short version in minor ways, put the Zlib FAQ question number into the link text, and ensure "PEP 440" uses non-breakable spaces.
... | ... |
@@ -1,11 +1,11 @@ |
1 | 1 |
# How to comply with the "altered versions" clause of the license |
2 | 2 |
|
3 |
-**Short answer:** change the package name and/or change the version number to include a [PEP 440][] "local version identifier". |
|
3 |
+**Short answer:** change the package name and/or include a [PEP 440][] "local version identifier" in the version number. |
|
4 | 4 |
If `derivepassphrase` ever rebrands, this applies to rebranded names too. |
5 | 5 |
We try not to clash with anyone else, and will yank our offending releases if we do. |
6 | 6 |
|
7 | 7 |
**Long answer:** We, upstream `derivepassphrase`, reserve the name `derivepassphrase` and certain version numbers for ourselves. |
8 |
-Specifically, our version numbers adhere to [PEP 440][] (or newer revisions) and generally do not include a "local version identifier". |
|
8 |
+Specifically, our version numbers adhere to [PEP 440][] (or newer revisions) and generally do not include a "local version identifier". |
|
9 | 9 |
To mark an altered version, we thus recommend that you change the software package name `derivepassphrase`, or use a version number with a local version identifier. |
10 | 10 |
If we (upstream) decide to use a local version identifier, we will avoid all clashing local version identifiers we are aware of, and if informed of a clashing local version identifier after our release, will yank our offending version(s). |
11 | 11 |
|
... | ... |
@@ -14,9 +14,9 @@ A change of package name does *not* by itself imply permission to use the old pa |
14 | 14 |
|
15 | 15 |
--- |
16 | 16 |
|
17 |
-See also [the zlib project's take on how to mark altered versions][ZLIB_FAQ]. |
|
17 |
+See also [the zlib project's take on how to mark altered versions (question #24)][ZLIB_FAQ]. |
|
18 | 18 |
Like them, we recommend keeping our upstream Changelog (up to the point where you introduced modifications) and describing your modifications both there and in the README, in the appropriate level of detail. |
19 | 19 |
We also request (but do not require) that you provide clear instructions in the README (and potentially other suitable places) on where and how to report problems that stem from your modifications, not from the upstream software package. |
20 | 20 |
|
21 | 21 |
[PEP 440]: https://peps.python.org/pep-0440/ |
22 |
-[ZLIB_FAQ]: https://github.com/madler/zlib/blob/v1.3.1/FAQ "see question #24" |
|
22 |
+[ZLIB_FAQ]: https://github.com/madler/zlib/blob/v1.3.1/FAQ |
|
23 | 23 |