search

propelorm / Propel2

Propel2 is an open-source high-performance Object-Relational Mapping (ORM) for modern PHP
http://propelorm.org/
MIT License
1.26k stars 399 forks source link

Pre-release versions not tagged according to Semver ("alpha.12" vs."alpha12") #1718

Closed pableu closed 3 years ago

pableu commented 3 years ago

I would like to see the pre-release version tagged according to https://semver.org/#spec-item-9:

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version.

This would mean to tag the current alpha as "2.0.0-alpha.12" and future pre-release versions accordingly (2.0.0-alpha.13, 2.0.0-beta.1).

This would immediately solve problems with https://github.com/fabpot/local-php-security-checker/issues/9 and https://github.com/FriendsOfPHP/security-advisories/issues/511.

dereuromark commented 3 years ago

For legacy and historical reasons this follows a slightly different notation that is also fully supported as such from composer - and as composer is the tool of relevance here, that might not be easy to change at this point.

As suggested in the tickets linked the tools here should adjust themselves to properly allow also valid variations without false positive alerts. They are there to support and validate the content, not to control how releases are done.

pableu commented 3 years ago

I understand where you're coming from and that you cannot easily change your versioning for historic reasons or because some tooling might depend on it.

Still, as I understand, "2.0.0-alpha12" is nota valid variation according to semver. It's simply an "accepted variation" because composer is more lenient than other implementations. It works by accident ;-)

The result is that propel still gets flagged for #1463, although it has been fixed a while ago.

But yeah, I see now that there are already a couple of issues around that on Github, and that issue this is also a duplicate of #1675.

dereuromark commented 3 years ago

Yes, and even if it was now fixed to a valid versioning for future releases, the security tool still must fix itself to allow the variations as otherwise people using the existing alpha versions that have the problem fixed would still appear as false positive. There is no way around it - a tool must fix itself here if it wants to be accepted.

SourceCode commented 3 years ago

This feels a lot like that XKCD situation where we now we need to make a third standard instead of complying with any of the previous ones.

dereuromark commented 3 years ago

I recommend making a ticket for composer then to make their tooling stricter here for future majors or alike. Maybe it could also issue warnings for certain legacy notations. Even though this will be super hard, as I am sure many customers are using outdated versions here for the last years and will do so decades more.

But force-changing an existing eco system (of valid and perfectly working releases here for composer none the less) is not an acceptable approach from a 3rd party tool like that.

Tags once released cannot be modified anymore, and we have already multiple of those out there that currently false positive on that named 3rd party tool.

pableu commented 3 years ago

If it wouldn't hurt, why not switch to the proper versioning scheme for the next release (e.g. 2.0.0-alpha.13)? This will improve the situation at least for everybody who upgrades to that version.

But force-changing an existing eco system (of valid and perfectly working releases here for composer none the less) is not an acceptable approach from a 3rd party tool like that.

I think of it more like PHPStan: It has revealed a potential issue that has been there for a long time.

I'll try to get fabpot/local-php-security-checker#26 merged.