In reply to @hmenke:matrix.org
I will tag a new release once that is resolved.

In reply to @muzzi:matrix.org
GitHub Action's scheduled workflow may be helpful for packages like pgf-pie that moves slow. For example, setting CI to run per week with -dev formats or so.

In reply to @hmenke:matrix.org
The downside is that scheduled workflows automatically get disabled if the repo hasn't seen activity for 90 days which will certainly happen for all those packages that are only in maintenance.

Even worse, it will be disabled in 60 days, not 90 days.

In a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days.
https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration

In reply to @muzzi:matrix.org
I'm wondering if the LaTeX Team is willing to make a workflow that triggers workflows of third-party packages each time when latex-dev releases.
It seems event repository_dispatch or workflow_dispatch is suitable for this task.

In reply to @muzzi:matrix.org
I'm wondering if the LaTeX Team is willing to make a workflow that triggers workflows of third-party packages each time when latex-dev releases.
It seems event repository_dispatch or workflow_dispatch is suitable for this task.

In reply to @muzzi:matrix.org

Even worse, it will be disabled in 60 days, not 90 days.

In a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days.
https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration

In reply to @marcel:2krueger.de
I think the timing would prove a bit difficult. After latex-dev releases a non deterministic amount of time passes before the update gets picked up by TeX Live updates, so this would have to be done manually. That would make it much less reliable.

In reply to @marcel:2krueger.de
You mean to install it manually? That might be doable even though it might need some additional setup. I'll do some experiments.

In reply to @marcel:2krueger.de
What if the workflow creates a commit in a dummy branch? 🤔

Heya, I'm considering opening an issue at GitHub with this MWE:

\documentclass[tikz]{standalone}\usetikzlibrary{plotmarks}
\tikzset{p/.style={circle,draw},mark size=+1.5pt}
\newcommand*{\T}[1]{\tikz[p/.append style={path picture={#1}}]{
  \node[p] (@) at (10,10) {0000};
  \draw[gray] plot[mark=x,mark size=+1pt](@.text);}}
\begin{document}
\T{ \draw[blue] plot[mark=asterisk](path picture bounding box.center);
    \draw[red] plot[mark=o] (0,0);
    \tikzset{shift=(path picture bounding box.center)}% no effect
    \draw[orange] plot[mark=triangle] (0,0); }
\T{ \draw[blue] plot[mark=asterisk](path picture bounding box.center);
    \draw[red] plot[mark=o] (0,0);
    \pgftransformshift{\pgfpointanchor{path picture bounding box}{center}}
    \draw[orange] plot[mark=triangle] (0,0); }

\T{ \tikzset{rotate around=45:(path picture bounding box.center)}% no effect
    \draw (path picture bounding box.center) -- ++ (0:4mm); }
\T{ \pgftransformshift{\pgfpointanchor{path picture bounding box}{center}}
    \pgftransformrotate{45}
    \draw (path picture bounding box.center) -- ++ (0:4mm); }
\end{document}

The TikZ transformation with shift and rotate around do not affect the coordinates but apropriate PGF transformations do.

Is this to be expected? That (0, 0) is at .text is to be expected (that's how nodes work) but I'm surprised the TikZ transformation don't work.

Or is a path picture just that bare that it won't support things like that?
(However, if I set \tikz@transform to \relax right before the \tikzset they do apply because apparently if not, the transformation only get collected for later.)

Qrrbrbirlbel: Try

\usepackage{xpatch}
\makeatletter
\xpatchcmd\tikz@finish
  {%
        \pgfinterruptpath%
          \tikz@path@picture%
        \endpgfinterruptpath%
  }{%
        \pgfinterruptpath%
          \tikz@transform
          \let\tikz@transform=\relax
          \tikz@path@picture%
        \endpgfinterruptpath%
  }
  {}{\PatchFailed}
\makeatother

Chances are that the #963 issue is a fake one, there's no problem in different "init" values for \tikz@transform". Letting it to \relax` means "now it's in outer mode hence every

Qrrbrbirlbel: Try

\usepackage{xpatch}
\makeatletter
\xpatchcmd\tikz@finish
  {%
        \pgfinterruptpath%
          \tikz@path@picture%
        \endpgfinterruptpath%
  }{%
        \pgfinterruptpath%
          \tikz@transform
          \let\tikz@transform=\relax
          \tikz@path@picture%
        \endpgfinterruptpath%
  }
  {}{\PatchFailed}
\makeatother

Chances are that the #963 issue is a fake one. There's no problem in different "init" values for `\tikz@transform".

• Letting it to \relax means "now it's in outer mode hence coordinate transformations can be applied directly".
• Letting it to \pgfutil@empty means "the collected coord-transformations are already applied, so it's time to clear \tikz@transform to make it ready for collecting new ones".

Qrrbrbirlbel: Try

\usepackage{xpatch}
\makeatletter
\xpatchcmd\tikz@finish
  {%
        \pgfinterruptpath%
          \tikz@path@picture%
        \endpgfinterruptpath%
  }{%
        \pgfinterruptpath%
          \tikz@transform
          \let\tikz@transform=\relax
          \tikz@path@picture%
        \endpgfinterruptpath%
  }
  {}{\PatchFailed}
\makeatother

Chances are that the #963 issue is a fake one. There's no problem in different "init" values for `\tikz@transform".

• Letting it to \relax means "now it's in outer mode hence coordinate transformations can be applied directly".
• Letting it to \pgfutil@empty means "the coord-transformations collected in inner mode are already applied, so it's time to clear \tikz@transform to make it ready for collecting new ones".