I’ve run into this situation with Log4Net. They’ve accepted my patch submission but haven’t yet released a new version (in years it seems).
So what I did was navigate to this directory:
Replaced the log4net.dll with my patched one. Checked it in.
What I’m counting on is that if 1.2.11 is *ever* released, I’ll just need to update my project and I’ll get those changes.
Downsides of course are:
Doesn’t help anyone else. I’m not too worried about this because I might be the only one to really care about my patch.
Log4Net might never release a new version. Again, not a big concern because I’m still ok.
Log4Net might release a newer version without my patch.
Now this would suck. In this case, it seems unlikely because they’ve already incorporated the code. But in the general case, this is entirely possible. If this happened, I’d have to patch the new version
and repeat these steps.
Now this only addresses the case where I’ve installed Log4Net as a consumer. Tatham’s case is more interesting because he’s writing a package that depends on the package that needs a patch.
For example, if I am building SuperLogger -> Log4Net 1.2.10, but SuperLogger needs a patch, one crazy idea would be to include support for patch dependencies.
SuperLogger 1.0 -> Log4Net 1.2.10, Log4Net 1.2.10.patch
When Log4Net 1.2.11 comes out, you can remove the patch dependency.
SuperLogger 1.0 -> Log4Net 1.2.11
What would the patch package do? It simply replaces any components of the package that it’s a patch for. The benefit is that if Log4Net 1.2.11 comes out independently, you could update that and the patch would
no longer apply and would no longer replace components of log4net.