Shouldn't this also enable the limited API so the changes are exercised immediately?

This PR only replaces a few functions that are outside the limited API set. I have split my original work into smaller chunks, that are easier to understand and review. There is a bunch of more work to do before I can enable the limited API, e.g. port LDAP_Type to heap type.

This PR only replaces a few functions that are outside the limited API set. I have split my original work into smaller chunks, that are easier to understand and review. There is a bunch of more work to do before I can enable the limited API, e.g. port LDAP_Type to heap type.

Right I assumed it was considered ready for review, not a draft?

Right I assumed it was considered ready for review, not a draft?

I don't follow. This PR is not a draft and is ready for review.

I'm sorry if I wasn't clear. I want to split the work on #540 into small, digestible chunks. Each PR will improve and change one aspect of the code base. Every PR will also leave the code base in working conditions with all tests passing.

This approach makes it easier for you and @droideck to review and verify the changes. Some changes are not obvious unless you are familiar with stable ABI and module states. I estimate that #540 is going to take around 6 to 7 PRs in total.

Hmm, sure, but at this point how do I tell whether the PR is useful? It gives no clear way to see if something has been missed for one.

I can see #540 is large and you want to split it into different parts (and get your point there) but I'd still expect each PR to be a patchset with a clear intent along the path that gets realised (somewhat) by the end of it, not necessarily one patch per PR if that makes sense? This PR as it stands looks like one commit that can't be reviewed alone, which might change if more commits were added to it (e.g. being able to limit ourselves to the stable ABI for 3.x+ and enforcing that).

You are welcome to disagree but then I'll have to recuse myself from reviewing this.

But this PR has a clear intent; it replaces several macros, one function, and one case of direct struct access with features from the limited API. To review the PR, you look up the documentation of each replaced function / macro, check that the old code is not marked for Part of the Stable ABI, and the new code is in the stable ABI for 3.6+.

You could argue that my patch may be missing some function replacements. That's not a problem, we can address that in another commit. The important bit is that this PR does not introduce a regression.