You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We either need to composer update and commit the new composer.lock with the coding standards 0.5.0, or remove composer.lock entirely. This would make ORCA somewhat less stable as a package (because end users would always get the latest version of dependencies on each ORCA build), but would prevent issues like this one and having to always chase upstream updates.
The text was updated successfully, but these errors were encountered:
Thanks, @danepowell. I've fixed and merged the immediate manifestation. Maybe we'll cut a release after the weekend. As to removing the composer.lock, I don't think we can do that. Not only would that destabilize ORCA in principle, it would result in unexpected effects on users. For example, if ORCA just downloads the latest coding standards on every build, a team whose static analysis passes today could start failing tomorrow without anything changing on their end. Then they have a fire drill. As it stands, we can alert users that changes are coming and document them in our release notes. Maybe the takeaway is just that we need to apply updates to coding-standards to ORCA more regularly.
This was fixed in acquia/coding-standards 0.5.0: acquia/coding-standards-php#10
But ORCA is still using 0.4.3: https://github.com/acquia/orca/blob/v2.10.0/composer.lock#L11
We either need to
composer update
and commit the new composer.lock with the coding standards 0.5.0, or remove composer.lock entirely. This would make ORCA somewhat less stable as a package (because end users would always get the latest version of dependencies on each ORCA build), but would prevent issues like this one and having to always chase upstream updates.The text was updated successfully, but these errors were encountered: