Am 11.03.2025 um 12:54 schrieb Gina P. Banyard <intern...@gpb.moe>: > Taking the example of ext/pcntl again, if it were a standalone extension, > having it follow semver is a way more reasonable proposition. > Because we could just release 2 versions the same day, a x.y+1.0 introducing > a warning, and a x+1.0.0 which would convert them into proper errors. > Meaning as a user, you could be running whatever PHP version and have the > stricter behaviour, or upgrade PHP while still holding the ext/pcntl version > behind while you deal with the issues.
I live in a world where a) people don't always control the PHP version they are using (hosted websites) and b) are using more and more packages which have to stay compatible for (e.g. security) updates to be applicable. My (sad) experience is that semver *does not* solve this, it just provides the concept of differentiating different types of changes and their respective compatibility assumptions. To be honest the pcntl example sounds like worst of both worlds: - Maintainers would have two (and later maybe even more) versions to maintain (for how long?). I'd rather have one version at a time and if I do not want to forget switching the warning to an exception at a specific point there are ample ways of doing this, e.g. a TODO/FIXME/whatever you want to call it marker somewhere which is automatically reported once the given criteria (time, version, ...) is met. - Would this be the only difference between these two version? If Yes then why have them in the first place (if you want to be strict about warnings then just convert them to an exception, that's easy enough). If No then you open yet another can of worms, e.g. one package requiring x.y+1 and another package requiring x+1.0. Been there, hated it :-) Regards, - Chris
