We've established the habit of numbering patches the following way:
0-499: All patches that are unconditionally applied
500-1000: Patches applied under certain conditions (e.g. only on RHEL8)
1500-1599: Patches for LLVM 15
1600-1699: Patches for LLVM 16
1700-1799: Patches for LLVM 17
...
2000-2099: Patches for LLVM 20
The idea behind this is that the last range of patch numbers (e.g. 2000-2099) allow
us to "deprecate" a patch instead of deleting it right away.
Suppose llvm upstream in git is at version 20 and there's a patch living
in some PR that has not been merged yet. You can copy that patch and put it
in a line like:
Patch2011: upstream.patch
As time goes by, llvm moves on to LLVM 21 and meanwhile the patch has landed.
There's no need for you to remove the "Patch2011:" line. In fact, we encourage you
to not remove it for some time. For compat libraries and compat packages we might
still need this patch and so we're applying it automatically for you in those
situations. Remember that a compat library is always at least one major version
behind the latest packaged LLVM version.
I've restored a patch for an older version of LLVM:
We needed to move the
`0001-Always-build-shared-libs-for-LLD.patch`
from the `0-499` range to the `19xx` (current release) and `20xx`
(snapshots) range. In addition the old version of the patch was restored
with the following command and added to the `18xx` range:
```
$ git show
0656f30e3739d2d371d58f2fad66d634a766e0fe:0001-Always-build-shared-libs-for-LLD.patch
> 0001-18-Always-build-shared-libs-for-LLD.patch
```
This was needed because the `bundle_compat_lib` (RHEL only) build
condition needs the old version of the patch.
