As per my comments in #1162:

• Deprecated features should be a warning
• Removed features should be an error
• New features should be an error
• For the few things which don't fall in the above categories: whether it is an error/warning should depend on how PHP handles the issue, i.e. does it cause a PHP parse/fatal error or a notice or warning to be thrown ?

Similarly for the error

native glibc (not-modified for graphene or USE_clone_FOR_fork defined) uses clone(2) syscall for fork(3) library function
as clone(CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHD, 0, NULL, &THREAD_SELF->tid)

This doesn't work as expected and the execution stalls somewhere. I guess it's not tested
because modified glibc uses fork(2) system call, not clone(2).

Once this is fixed, glibc modi

I am contributing to a project where the maintainer has set up revapi. Sometimes when I e.g. add a new method to a public API, revapi warns me during the maven build, that this will break semantic versioning. And I think this is great.

But then I got a problem, because I don't know by heart, if I have to increase the patch, minor or even the major version. So it would be really helpful to inclu

CompatHelper can open many PRs and push all non-CompatHelper related PRs off the first page of a project's PR list. It would be great if CompatHelper labeled its auto-generated PRs with a CompatHelper label so it is easy to filter out these PRs with a simple -label:compathelper argument to the PR search.

cc: @leios @vchuravy