Fixed ZF1F version in composer.json to avoid conflicts with our patches

[fballiano]

when implementing our composer patches for ZF1F we didn't consider that our 20.1.0 tagged release can't now run a composer install because ZF1F is now been updated and the patches can't be applied anymore.

Explanation at #3474

Thus we have to specify the exact version number of ZF1F in the composer.json.

Fixes #3474

[fballiano]

composer validation is complaining but we have to do it this way... I don't see any other possibility

[ma4nn]

composer validation is complaining but we have to do it this way... I don't see any other possibility

as mentioned in #3474 another possibility would be to use composer patches plugins such as vaimo/composer-patches that can handle version constraints for the patches

[fballiano]

@ma4nn so sorry, I'll check it out immediately!

[fballiano]

so, I was checking this matter more in detail, but I still think we should have a strict version dependency here.

let's make this example

• now main is compatible with latest version of zf1f
• we can't add any version constraint to the patches because we have no idea if some of them will ever be integrated in zf1f in the future
• 1.23.5 could have one of the patches, or not, so we can't constraint "now" to "use this patch only if <=1.23.5 because we may need the patch in the next version, or not

am I getting something wrong?

[fballiano]

@kiatng @elidrissidev @colinmollenhour @addison74 we've to address this as soon as possible and tag a new release, at this moment all installations via composer are broken

[ma4nn]

@fballiano yes you're right, there is no optimal solution.

My (untested) idea was to constraint e.g. the MAG-1.9.3.9.patch to "shardj/zf1-future": "< 1.22.1".

Imho the whole idea of the composer patches is to live with the fact that there may be future updates to the patched library that will make your patch fail as you mentioned. In this case one could either add a patches-ignore section to their own composer.json or wait until the patch version constraint is updated with the next OpenMage version.

This approach has the benefit that you profit by updates of the zf1-future library without releasing a new OpenMage version which is very important imho.

[fballiano]

My (untested) idea was to constraint e.g. the MAG-1.9.3.9.patch to "shardj/zf1-future": "< 1.22.1".

sure, but that patch is already removed from our composer.json for, for a next release, we don't have a need for the version contstraint, but it doesn't fix the problem anyway, sadly

This approach has the benefit that you profit by updates of the zf1-future library without releasing a new OpenMage version which is very important imho.

with our fast pacing updates I don't think that we really need to allow zf1f updates, and allowing the upgrade with a failing patch could be tricky too :-\

[addison74]

From the conversations I followed carefully, I think the two patches should be removed (I think this has happened) and a new version must be released. When OM it is installed with Composer, it will get the current ZF1-Future version, according to the version mentioned in composer.json.

Also, the current OM version is either completely removed, or we correct it with a ZF1-Future version up to X, as you also showed.

The less pleasant part is that we have to be careful when a new version of ZF1-Future is launched and not to approve the automatic the PR created by the bot without checking the existing patches.

[fballiano]

The less pleasant part is that we have to be careful when a new version of ZF1-Future is launched and not to approve the automatic the PR created by the bot without checking the existing patches.

not really, because our composer requirement for zf1f allows the upgrade regardless we approve that automatic PR or not

[colinmollenhour]

I agree that the version should be fixed given the circumstances. If there is a critical update, dependabot should tell us, right?

[fballiano]

@colinmollenhour dependabot will tell us 1 week later (in the worst case)

thing is, composer validation is complaining not to use exact version number...

[colinmollenhour]

Is it ok to use composer validate --strict --no-check-all?

[fballiano]

I was checking that parameter earlier but the documentation is not super clear to me, anyway I think it’s our only way

[addison74]

I am not an advanced Composer user, but maybe we should ask for an opinion in their forum. I noticed that there are quite interesting discussions on various topics.

https://github.com/composer/composer/discussions

[fballiano]

ok from https://getcomposer.org/doc/03-cli.md it's clear that the no-check-all is the parameter we want in this case:

--no-check-all: Do not emit a warning if requirements in composer.json use unbound or overly strict version constraints.

[fballiano]

@colinmollenhour we will have to address this also in v19 because composer installation are broken in v19 at the same way...

[addison74]

Reading the documentation, we don't really have other options. What @colinmollenhour proposed would be the solution.

[fballiano]

it's already implemented in this PR ;-)