@ronkok here:
... #2219, which was fixed by PR #2220 in March. The problem is that we have not had a release issued since September. There are also some bug fix PRs waiting for review, much less release.
We should review at least the bug-fix PRs, and then do a release. (Sorry, I've been slacking on this as much as everyone.) @ronkok, can you list which PRs you think are important and/or easy for review before release, so we can prioritize? I'll then make a list here that can track progress:
Bug fixes:
\substack has no argument.\\\boldsymbol{\Omega}trust\i spacingPRs that aim at making the documentation more clear or complete:
Bug fixes:
\substack has no argument.Others have contributed PRs that aim at making the documentation more clear or complete:
There are also some cool feature enhancements, but we should not wait for their review. We ought to get a release out right away.
If possible, it'd be best get either #2156 or #2134 merged, but as it has been a long time since the last release, I don't mind including them in the next release.
It'd be nice to get your nice PRs #2134, #2131, #2085 merged, but that is probably a larger effort. I'm imagining 0.12.0 would be good to just get the various improvements over the last six months, but as #2134 is a breaking change, maybe someone would want those improvements (including bug fixes) without having to adjust their code to avoid relying on greediness. (I'm wondering whether it would be better to do a deprecation warning in a release beforehand...? Or keeping greediness, but with a nonstrict warning? Anyway, would kinda like to push this off...)
@ylemkimon When the time comes (hopefully soon), do you want to do the release process or should I? You've done it more recently, so it might be easier for you (happy to review the resulting PR), but I'm also willing to do it.
I can do it. Another concern is #2082, which may cause security issues. I think its documentation may be insufficient.
@ylemkimon Could you elaborate on the lack of documentation? I looked at https://katex.org/docs/next/supported.html#html and the strict documentation in https://katex.org/docs/next/options.html and it seemed OK in terms of security. We just need to be careful in the release notes to point out that there's new security options, so security: true has a different meaning now than before.
Perhaps the rendered form in https://katex.org/docs/next/supported.html#html would be clearer if we also included the raw HTML repeated like ...<span class="enclosing" data-foo="a" data-bar="b">...x...</span>...?
@edemaine I don't have any specific thoughts, but for instance, https://github.com/KaTeX/KaTeX/pull/2296/files#r453218268. I think we should explicitly state there exist commands that loads external resources or change HTML attributes.
@ylemkimon Perhaps we've reached a good time to do a release? Or did you want to finish #2301 first?
@edemaine I think it'd be safe to do with the current environment. I'll prepare a release PR.
Most helpful comment
@edemaine I think it'd be safe to do with the current environment. I'll prepare a release PR.