Bump PHP API numbers and versions

[petk]

API was changed since the last bump 8ec0cf8

[nikic]

During the pre-release phase API version numbers are not bumped. There will be a bump somewhere close to the PHP 7.4 release, when we are sure that no more API changes are necessary.

[petk]

Thanks for the explanation @nikic.

cc @EricSten-MSFT see above explanation ☝️ ... I think extensions should be able to be built using the current API version...

[nikic]

Just fyi, I recommend doing API checks in code based on PHP_VERSION_ID, which tends to be clearer than the ABI numbers.

[EricSten-MSFT]

@nikic FYI, PHP_VERSION_ID hasn't changed between php7.4.0alpha1 and php7.4.0beta1, so can't be used in an #ifdef to prevent using the code which was removed in your commit.

[Majkl578]

@EricSten-MSFT PHP_VERSION_ID doesn't include pre-release information, PHP_VERSION does. There is also PHP_EXTRA_VERSION.

[EricSten-MSFT]

@Majkl578 That's nice, but still can't be used in an #if preprocessor directive. There's no way to do a string comparison in a C preprocessor comparison directive. Which is why we have the *_VERSION_ID #defines. Thx!

[nikic]

@nikic FYI, PHP_VERSION_ID hasn't changed between php7.4.0alpha1 and php7.4.0beta1, so can't be used in an #ifdef to prevent using the code which was removed in your commit.

I think I haven't been clear enough here: Extensions can not and should not support anything but the latest pre-release version. There is no need to distinguish between alpha 1 and beta 1, because beta 1 is the only thing that needs to be supported (for the cases where it makes a difference).

API changes in pre-release versions happen very often and are not subject to fine-grained tracking, on the assumption that it makes little sense for extensions to support all random snapshots of master -- ultimately they just need to support the GA release. The internal API and ABI become mostly stable at beta 1 (which is now), though there may still be changes if they turn out to be necessary. API and ABI are fully frozen prior to GA and are assigned final numbers that will remain unchanged for the whole minor version from that point on.

I hope that makes some sense. We could of course change our procedure and for example start assigning new API/ABI numbers for each alpha/beta release to allow extensions so that extensions can be compatible with each pre-release. I'm not sure I see what the value in doing that would be though.

[petk]

Well, if I understood this correctly technically, we should bump these numbers, yes for each milestone i.e. the tag. Otherwise, PHP extensions should according to this now take into consideration only states of PHP between versions of PHP 7.3.x and PHP 7.4.0. From PHP extensions point of view there is no difference between the alpha, beta or final GA release then. So a simple ditch of alpha versions is a precondition here for fixing the extensions code out there. Users won't be having alpha somewhere and beta release somewhere else. Yes, there are hosting services that provide RC releases already but I think GA should be the final target for all then.

[EricSten-MSFT]

@nikic Ah, okay, so, you're saying that I don't have to worry about compiling for alpha1, now that beta1 is out. Got it. Thx!

[nikic]

Ah, okay, so, you're saying that I don't have to worry about compiling for alpha1, now that beta1 is out. Got it. Thx!

Yeah, that's right!