tikz fails to load since May 2019 update

[xirk]

I use plain TeX, using pdfTeX with tikz to get maths and science diagrams. I run TeXLive using the manual installer which I run an update every few days or so. I am using Manjaro Linux.
Since the latest update (3.1.3) dated approx 14 May 2019, errors occur after "input tikz":

File being loaded was:
/usr/local/texlive/2019/texmf-dist/tex/generic/pgf/frontendlayer/tikz/tikz.code.tex
line 577: Undefined control sequence.
\pgf@setup@shading@model ...delgrayfalse \XC@sdef
(plus a few other similar undefined controls)

The pdf document produced starts with the word "natural" repeated 3 times, inserted before the first actual intended text.

I did not notice any new required files in the latest version of the manual. Am I missing something?

[hmenke]

It's a regression which affects both Plain TeX and ConTeXt. With the latest version of TikZ the shadings are now colorspace aware, but that requires some collaboration with the xcolor LaTeX package. There are two control sequences which have to be defined for this to work.

Workaround for Plain TeX:

\catcode`@=11
\def\XC@tgt@mod#1{#1}
\def\XC@sdef#1#2{\edef#1{#2}}
\catcode`@=12
\input tikz
\bye

Workaround for ConTeXt:

\unprotect
\def\XC@tgt@mod#1{#1}
\def\XC@sdef#1#2{\edef#1{#2}}
\protect
\usemodule[tikz]
\starttext
\stoptext

[Ndolam]

Ummm... is a fix going in for this? Or should plain TeX and ConTeXt users use these work-arounds for the foreseeable future? If the latter, would it not make sense to put these lines of code in (e.g.) tikz.tex ?
Thanks.

[hmenke]

If you had read this thread carefully you'd have noticed that this was fixed in 8379e59, i.e. it's going to be in the next release. If you can't wait for that and you're using TeX Live, you can use the tlcontrib repo as described in https://github.com/pgf-tikz/pgf#installation.

[Ndolam]

Hmmmm... after closely rereading the contents of #675 , I don't see where it says it was fixed. Perhaps you see different text than I do. For 8379e59, all I see is "Verified 8379e59" which does not suggest a fix is in the works to me. Am I supposed to know "Verified" means "fixed" ? If so, I guess you could have told me I need to learn github, not that I didn't read this carefully. Most (if not all) places where I read bug reports, if someone fixes something in the code base they actually say that (in words) when they put the fix in. Thus my confusion here.
Thanks for the fix.

[hmenke]

When I look at this issue I see two explicit references that this has been fixed and one implicit one (if there is a ticket number in the title of a commit, it's always a fix).