LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Thu, 23 Jul 2020 16:06:52 +0200
text/plain (68 lines)
Hi Henri

> Inspired by issue #900 on the PGF/TikZ repo [1], 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 
supported interfaces

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.