Thu, 23 Jul 2020 16:06:52 +0200
> Inspired by issue #900 on the PGF/TikZ repo , I'd like to kick off
> the discussion on how to correctly integrate the new hook management
> system into existing LaTeX package codebases.
> In a naïve adaptation, two code branches would be maintained, with and
> without the new hook management. This is quite tedious for maintainers,
> especially when trying to integrate this properly into existing CI.
As you say there has to be some transition time and that puts some
burden on maintainers if they want to provide compatibility with
different versions of LaTeX out there in user installations.
Life would be easy if people would update their installations as a whole
but as we know some people run some very old TeX distribution but then
try to upload individual packages from CTAN.
When it comes to a large functionality increase (like the hook
management offers) then it really depends on how (or if) a package makes
use of it for the best kind of approach.
Case A: you don't use it or only through already existing legacy but
If the package just uses \AtBeginDocument, or say the hooks offered
through etoolbox etc, then everything should be transparent
Case B: you intend to use the new functionality in earnest, e.g., by
adding your own hooks or add code to hooks not available in the kernel
In that case I think the best approach is to consider the earlier
implementation of the package as "frozen for older kernels" and
structure your package as follows:
% this because it is also fairly new:
% load frozen version for older kernels
% needs to be separate to apply to right file
% code for current version
This way all actively maintained code is in one place without code
branches other than at the very top to pick up the frozen version.
If the package in this form would be now placed on CTAN it would work
both in latex-dev and latex (running any older kernel)
After release of 2020/10/01 there is then the option to keep this
version of the package or at some later stage replace the top by
to declare that the package on CTAN needs at least this kernel version.