Will the cmark-gfm branch continue to be maintained for awhile?

[digitalmoksha]

What is your thinking on maintaining the cmark-gfm branch of commonmarker? I'm a little concerned about those of us currently using it, and should new versions of cmark-gfm be released (security and/or bugs), will we see these updates here?

Since you're moving to a completely different toolchain, it would take time to transition, assuming that an infrastructure department would approve the use of Rust libraries (shouldn't be a problem, but I also know it's possible).

Also, since there is certain support still missing from comrak, particularly kivikakk/comrak#232, we wouldn't be able to use it anyway.

[gjtorikian]

What is your thinking on maintaining the cmark-gfm branch of commonmarker? I'm a little concerned about those of us currently using it, and should new versions of cmark-gfm be released (security and/or bugs), will we see these updates here?

The short of it is: maybe. Right now, GitHub uses the cmark-gfm branch, so I've kept it up for @phillmv and others to make releases to that implementation. Since they are just as keen as providing timely security updates to themselves, and have shown in the past (GHSA-fmx4-26r3-wxpf, GHSA-4qw4-jpp4-8gvp) to provide patches, I assume that those security updates will continue to be provided. As for me, I have no interest in maintaining C code anymore outside of this one use case. If someone else wants to keep making updates, they're more than welcome to fork the project.

Also, since there is certain support still missing from comrak, particularly kivikakk/comrak#232, we wouldn't be able to use it anyway.

I'll do my very best to implement comrak changes here as soon as they land.

[digitalmoksha]

Sounds good, thanks!