PCRE2 10.45 release plan

[NWilson]

Hi,

Is there a roadmap for the next release? I get the sense that PCRE2 releases happen "as needed" rather than based on specific feature goals or a regular bi-annual cadence.

Are there things that Zoltan or Carlo are planning to get into the next release? Or will it just go out "whenever"?

From my point of view, I'm hoping to finish up my current draft PR on [a-z -- m] extended classes, which I would like to be in the next release. As a stretch goal, I will hopefully one day add support for (?[...]) classes, but that is dependent on when I get some free time to research the precise parsing rules that would be required for accurate Perl compatibility.

Beyond that, other things that I've suggested working on are purely non-observable cleanup or optimisation tasks (like OP_CHAR2, or simplifying/removing PT_CLIST); therefore I don't feel a particular sense of urgency to get them done in order to squeeze them into the next release.

We were hoping that v10.45 might perhaps be released before the end of 2024, if that's feasible. The NEWS file is certainly going to be a very fat one compared to the last couple of entries!

[PhilipHazel]

You are right about "as needed", though I have tried vaguely over the years to do two releases per year. In the light of the recent burst of activity I have been wondering when the next one should be. Because there have been so many substantial changes, I feel that we ought to put out a Release Candidate and encourage people to test. When I've done this in the past, I have always left at least one month between RC and actual release. Getting something done by the end of 2024 seems very tight.

I hope you (or someone else) will get the Perl $([ syntax working because I think I would feel uncomfortable releasing only the non-Perl extended class syntax. Once you have completed the other syntax I could take a look if nobody else can.

[NWilson]

OK, I can step up to do the "(?[...])" support. It's just the code to convert the pattern string into the META codes that we need. I don't think the Perl syntax needs any special METAs, and can output them in the same layout as the UTS#18 syntax.

[NWilson]

I appreciate your careful approach to stable releases, and we won't rush your schedule.

[NWilson]

@zherczeg @carenas @PhilipHazel

I am hoping to put out the 10.45-RC1 release before Christmas. That doesn't seem too rushed a schedule.

• Test coverage is good
• We have UTS#18 and Perl extended character classes, and working JIT support for them
• The backlog looks healthy - not many tickets at all really which demand attention before we do a release

I have tagged open issues here, which I think should be sorted out before the 45-RC1: GitHub issues list

On top of that, I have some non-code "release" tasks to complete (read-through of docs, update ChangeLog, rehearse the release procedures).

Let me know if there's anything else that should be added as a must-do task for the RC1 - code tasks, or additional testing. Current testing will certainly involve building & running the unit tests on a variety of OSes.

[carenas]

• The backlog looks healthy

problem is we don't usually have a backlog (at least not a visible one), but I think we have only a few blockers for a release IMHO.

is your suggestion to do an RC1 ASAP, a veiled way to ask for a "code freeze"?

[NWilson]

It's an open way to ask for a "code freeze". I think we're all expecting a release soon. I want to know what you all think - are there any tasks which you think we should complete, before the next release?

[zherczeg]

I am working on some eclass jit improvements at the moment. Smaller scope patches. For example, I want to remove PT_ANY from all matchers, since the parser handles it.

[PhilipHazel]

Sounds like a reasonable plan. I will let you have a list of contributors scraped from old ChangeLog files later today.

[carenas]

are there any tasks which you think we should complete, before the next release?

since we have never done a "code freeze", if you consider the requirement to be "a fix for a regression that will be otherwise introduced with this release", I think you already have those on your tags, but there might be more (which might not be technically a regression) like:

• FTBFS in old Solaris with gcc < 5 (loosely connected to x86: improve SIMD detection zherczeg/sljit#257, and likely also affecting old Linux, like CentOS 7)
• seems at least in AIX a generated snapshot wouldn't run its tests
• there is an ugly workaround for a macOS libc bug (originally an stackoverflow question) that might need cleanup. This might also improve support in OpenBSD and Linux that use a UTF-8 C locale by default (like Alpine)

Those fixes are not forthcoming though, as I had been unable to secure enough "free" time to work on them (including some on your list)

[NWilson]

seems at least in AIX a generated snapshot wouldn't run its tests

I saw that failure. It looked like you were running a tarball from "make dist", and then doing "make check". There was indeed a bug, due to the new testdata files not being include in "make dist", and I found & fixed it just yesterday in #603.

Hopefully this one is sorted.

there is an ugly workaround for a macOS libc bug thst might need cleanup. This might also improve support in OpenBSD and Linux that use a UTF-8 C locale by default (like Alpine)

That sounds worrying. Is there a ticket for it?

[NWilson]

@carenas

there is an ugly workaround for a macOS libc bug thst might need cleanup. This might also improve support in OpenBSD and Linux that use a UTF-8 C locale by default (like Alpine)

I've tried hunting for this issue in the GitHub issues tracker, but I can't find it. I guess I'm using wrong keywords to search? I can look into the issue, if you point me to it.

[NWilson]

@zherczeg I have no further PRs to open; the two at the moment are my last two for 10.45-RC1.

There's absolutely no rush - have a great Christmas!