\IfInstanceExistTF unavailable in 2024-06-01 pre-release 1

[muzimuzhi]

Brief outline of the bug

At the time when 2024-06-01 pre-release 1 was released, \IfInstanceExist(TF) were both removed from the new kernel code and latest xtemplate package. Therefore in current -dev formats, \IfInstanceExist(TF) are always undefined with or without xtemplate package loaded.

This introduced a regression that packages which load xtemplate and make use of \IfInstanceExist(TF) may not work with 2024-06-01 pre-release 1, for instance xeCJK (CTeX-org/ctex-kit#707).

As these commands were already reintroduced to the kernel (41f33bc4 (Re-introduce \IfInstanceExist(TF), 2024-02-15)), a new pre-release would resolve the problem.

Minimal example showing the bug

\RequirePackage{latexbug}       % <--should be always the first line (see CONTRIBUTING)!
\documentclass{article}
\usepackage{xtemplate}

\show\IfInstanceExsitTF

\begin{document}
\end{document}

Release	xtemplate loaded?	\IfInstanceExsitTF defined?
2023-11-01 (e.g. pdflatex )	F	F
	T	T
2024-06-01 pre-release 1 (e.g. pdflatex-dev)	F	F (should be T)
	T	F (should be T)

Log file (required) and possibly PDF file

latex2e-no-IfInstanceExistTF-in-2024-06-01-pre-release-1.log

[josephwright]

Sure, but this is a pre-test ;) So it's always possible you have to make minor adjustments in your sources as things get tested.

A new dev release is likely before Easter, we are just finishing off some additions and will likely agree on things on Tuesday.

[FrankMittelbach]

@muzimuzhi -dev releases are for testing and yes, sometimes they show a breakage that was intorduced by mistake. That doesn't mean that we immediately intoroduce a new release. Please understand that overall making a dev release results in several hours of work for both us and the CTAN folks combined and we have to be careful in managing the limited resources here.

[mrpiggi]

@FrankMittelbach I totally get this argument. But as developers are encouraged to use latex-dev in order to detect possible breakages early and they do this in an automated test suite---not that I am doing this, long outstanding issue for myself---than those regression can get annoying like in the case of @muzimuzhi. Wouldn't it be possible to create an identical release for latex-dev with every major release? Or would this need the whole manual process for latex-dev as you described?

[FrankMittelbach]

My take on this is that one can and should have a testsuite set up so that it can use either or latex or latex-dev format. Yes we encourage developers to test against -dev but obviously you also need to test against main because most of your users will be using main andd if something is reported as broken one needs to see what fails with main and how to fix that.

So the idea is that a test suite should report success with main and you should regularly run it using -dev and see if this this breaks anything and if so report a problem to us -- or fix your code to work both with current main and -dev aka upcoming main if it is a legitimate change.

For example, I run all of the TLC3 sources against -dev usually to ensure that the book is not broken with the next main, but because of the \IfInstanceExistTF issue I had to fall back to "main" at the moment and wait for a new -dev release to appear.

The "identical release of latex-dev for each major release" is the latex release without -dev in the name so I'm not what you are asking and yes making another release with a different name introduces the same amount of work ... it is making a release that is the work (and get it through all stages) even though a lot of it is automated.

[mrpiggi]

My take on this is that one can and should have a testsuite set up so that it can use either or latex or latex-dev format.

Agreed

The "identical release of latex-dev for each major release" is the latex release without -dev in the name so I'm not what you are asking and yes making another release with a different name introduces the same amount of work ... it is making a release that is the work (and get it through all stages) even though a lot of it is automated.

I asked having some automated test suite in mind running for both latex and latex-dev formats which could fail running latex-dev like in the case @muzimuzhi described. Having both releases in sync would not break any tests for latex-dev without any obvious reason. But as I said, I totally get the point regarding the efforts to take. I just wondered if this would be achievable easily.

[josephwright]

@FrankMittelbach I totally get this argument. But as developers are encouraged to use latex-dev in order to detect possible breakages early

I guess that's what I feel is happening: you test, there's an issue, you patch round it until the next dev release ...

[FrankMittelbach]

I asked having some automated test suite in mind running for both latex and latex-dev formats which could fail running latex-dev like in the case @muzimuzhi described. Having both releases in sync would not break any tests for latex-dev without any obvious reason. But as I said, I totally get the point regarding the efforts to take. I just wondered if this would be achievable easily.

sorry, I'm still not getting what you are after.

Suppose you have a simple setup:

• your test suite just tests against main
• now we put out a hotfix for main (or we release a new main)
• your test suite breaks
• if the breakage is caused by something bad in your package you fix your package
• otherwise you report an issue with us (but your test suite remains broken until this is fixed or you temp program around it)

you wouldn't expect in this case that CTAN keeps 2 releases of main, would you?

Now assume your test suite runs both main and -dev tests

• now the -dev release suddenly breaks
• if that is due do something you shouldn't have done in your package or because we cleaned things up and some interfaces require adjusting, you update your package so that it works both with main and upcoming -dev
• otherwise, something is wrong with the new -dev and you report it
• then for the time being you have to disable -dev tests until we have a new -dev out
• that is precisely the same as if main breaks and we need to have a hotfix out (only that with main it is more urgent and we try to make that happen fast usually)

What I could envision (and perhaps that is what you are asking) is some flax or config setting that allows you to run your test suite in 3 modes:

• only main
• only -dev
• both main and -dev

but to have yet another full latex distribution as in latex-previous-dev seems overkill to me because that is much better done by not testing -dev for a while (but maybe you didn't mean that).

[mrpiggi]

you wouldn't expect in this case that CTAN keeps 2 releases of main, would you?

Nope, I wouldn't. I am only talking about the point, where dev is not up-to-date with main. But now I can see, that this isn't the point and I am talking nuts.

At the time when 2024-06-01 pre-release 1 was released, \IfInstanceExist(TF) were both removed from the new kernel code and latest xtemplate package.

By reading "new kernel code" I mistakenly assumed, that this is already out in main. But we are only talking about an intermediate state of dev. And well, that is something what could happen as the name intends.

As far as I can see, there is actually a new release of dev with every major relase of main. The case where main is ahead of dev occurs only if there is a new patch release but this is fine, I guess.

Sorry for the noise.

[FrankMittelbach]

yes we add a dev 0 very soon after each main (just wait a bit in case we have overlooked something and need a patch release) so usually, dev is ahead of main (and even after a new release of main it is more of less = to main so on this front we are usually ok even in the daves directly after the main release).

as a new dev is going to show up real soon* I'm going to close this issue.