[RFC]: stop testing `latest` dependencies about laminas-ci-matrix-action

[boesing]

I see the point here and I am fine with the change.

Still want to say that my current pipelines (in pet projects) do depend somehow on that (which I only trigger via weekly builds as I do not have renovate up and running - yet).

So whatever change we make here should ofc reflect the needs of the laminas ecosystem but we should keep in mind where this all comes from and who is using this - since we published it as a publicly available action, we should kinda try to stick with decisions we made before - even tho they start being inconvenient at some point. If we start building a CI pipeline around renovate, we should properly note this in the documentation and create proper documentation on how to have a proper build pipeline along with renovate + the laminas CI stuff.

[Ocramius]

I'll implement this (it's mostly code removal), and will patch the docs accordingly.

/cc @lcobucci IMO this is the last 2.0.0 change, then we can try out 2.0.x on some repos, and finally release :)

[internalsystemerror]

Yeah makes sense. With the lock file constantly updated, that now makes the latest tests redundant. +1 from me.

[weierophinney]

I was going to say "hell no", but then read the bit about updating composer.lock nightly, and it all makes sense. 👍 from me.

[Xerkus]

The point of latest is to notice those upstream breakages. And point of lock file is to quickly detect when those breakages are not something introduced by tested changes. With lock file maintenance in place the lock file covers both points so it make sense to remove latest. BUT lock file is only usable for the php version it was generated on. So latest would need to stay on any other php versions.

[Ocramius]

The problem with latest as it is configured right now is that it conflicts with completely unrelated CI pipelines. Contributors would get red builds for changes they had nothing to do with, and the same would apply to Renovate overnight updates.

So latest would need to stay on any other php versions.

Kinda agree that we need to somehow probe newer PHP versions with newer dependencies, and that we cannot run locked against newer PHP dependencies either (simply won't run, sometimes).

Perhaps sticking with lowest only (for newer PHP versions) is a safe-ish solution here, for now 🤔

[boesing]

When I read this correct, most issues were runtime deprecations? Pretty sure that we explicitly want these - I was like "hell disable phpunit deprecation exceptions" in the past 😁

Might still be a way to go. I was working on testing if we can have Jobs which may fail. Could still be something to be added to the matrix as a dedicated Job tho. Having deprecation warnings in phpunit confuse a lot but I see why we might want them - its just not a good place to trigger contributors attention because of that.