About Release Tags applying semantic versioning

[kayw-geek]

@TomasVotruba Currently, using version numbers like "1.0.0" and "1.0.0.72" might be confusing, as according to Semantic Versioning standards, "1.0.0" and "1.0.0.72" should be considered as the same major and minor version, with only the .72 differing. Typically, this would be understood as "1.0.0" being an older version, while "1.0.0.72" is a newer version. And in the composer.json file, if I specify ~1.0.0, it will always automatically upgrade to 1.0.0.72. So, should we consider using two different major versions to distinguish them?

[TomasVotruba]

Ideally, there should be only single tag with downgraded and scoped version.

[kayw-geek]

Shall we retain the downgraded version number as 11.x.x and upgrade the main version number to 12.x.x? Is this agreeable?

[TomasVotruba]

I see. The main version should be tagged, but then build and forcepushed with downgraded code. That way any version you'll install will support PHP 7.2 and have no conflicts.

So instead of 11.x.x.72 and 11.x.x (now), there will be only one 11.x.x with downgraded code.

Something similar is done in easy coding standard ↓ https://github.com/easy-coding-standard/easy-coding-standard/blob/b155b4f1b133166d2ad9194bce0a0359d1baa6db/.github/workflows/downgraded_release.yaml#L84-L92

[kayw-geek]

Does this mean it overrides the code for PHP 8.1 version? So, in essence, users utilizing PHP versions >= 8.1 are actually using code that's compatible with 7.2?

[TomasVotruba]

Yes, exactly :+1: that's the goal. Also the downgraded version is scoped. That means you can install it on Symfony 3, 4, 5, 6... even if we use Symfony 6 here.

Here are 2 posts that can explain it better:

• https://getrector.com/blog/prefixed-rector-by-default
• https://getrector.com/blog/how-all-frameworks-can-bump-to-php-81-and-you-can-use-older-php

[kayw-geek]

I got it, the rector is very convenient and powerful, after I will fix the version number according to you said

[kayw-geek]

I got it, the rector is very convenient and powerful, after I will fix the version number according to you said

[kayw-geek]

@TomasVotruba There have not any require packages in the build/target-repository/composer.json file, when users run the composer install command, the libraries that monorepo builder depends on will not be installed either?

[TomasVotruba]

That's correct! Those dependencies are scoped and delivered as part of own /vendor directory.

E.g. if you check last *.72 tag, there is everything neede for the project to run: https://github.com/symplify/monorepo-builder/tree/11.2.4.72

[kayw-geek]

@TomasVotruba I understand that this version includes the vendor directory, which results in a larger package size. As for your question on Twitter, you can use phpunit --testdox --verbose to display detailed information.

[TomasVotruba]

As for your question on Twitter, you can use phpunit --testdox --verbose to display detailed information.

Thanks for help!

I've actually try that at start, but it fails on PHPUnit 10.3.1 :crying_cat_face:

[kayw-geek]

@TomasVotruba There's another issue. Currently, pushing a tag triggers a downgrade to 7.2 and then triggers a Bare Run. However, if these are switched to the same tag, this means the Bare Run will be executed twice.

[TomasVotruba]

That might happen, but the 2nd one is the one that counts and will be displayed on the repository.

Check the ECS repository for validation, as that's working well.