Mention also API versions bumps

[petk]

Few clarifications based on the explanations and current practices in the release process docs.

See #4468

[cmb69]

Thanks!

[nikic]

Not sure this is right wrt GA release?

Also @derickr implied that it should be bumped at RC, not sure what past practice here was.

[cmb69]

PHP 7.2 and 7.3 had their latest bump around beta1. Bumping at RC or shortly before GA should be avoided unless necessary, since that would require all extensions to be rebuilt.

[petk]

Alright, since this is not something written in stone or a part of a strict protocol, I've then added the following change:

 5. Bump the version numbers in `main/php_version.h`, `Zend/zend.h`,
    `configure.ac` and possibly `NEWS`. Do not use abbreviations for alpha and
    beta. Do not use dashes, you should `#define PHP_VERSION "7.4.22RC1"` and
    not `#define PHP_VERSION "7.4.22-RC1"`.

    When releasing the first alpha version, bump also API version numbers in
    `Zend/zend_extensions.h`, `Zend/zend_modules.h`, and `main/php.h`. The API
    versions between the alpha/beta/.0RCx releases can be left the same or
    bumped as little as possible because PHP extensions will need to be rebuilt
    with each bump.

Just so it is a bit more clear. Yes, I thought that basically feature freeze is the date of the API version number bump. With feature freeze, the ABI shouldn't change also... But ok, no worries. RCs are a bit more tricky then already, yes. Because there might even be an option to use it on the hostings out there already.

[derickr]

beta1 makes the most sense to me, as that's the feature freeze. Or perhaps RC1, as that's more of a hard ABI freeze, and still early enough on to retest new extensions with the same ABI. alpha1 sounds too early.

[derickr]

I think I'd like to bump it with beta3 - as a bump is necessary. Does anybody object? /cc @remicollet