Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restore Composer 1 support in the 2.x branch #620

Closed
mxr576 opened this issue Nov 13, 2020 · 11 comments · Fixed by #645
Closed

Restore Composer 1 support in the 2.x branch #620

mxr576 opened this issue Nov 13, 2020 · 11 comments · Fixed by #645
Assignees

Comments

@mxr576
Copy link
Contributor

mxr576 commented Nov 13, 2020

Hi,

Today we bumped into an issue because Composer 2 compatibility was suddenly dropped by this plugin and our builds have started to break in those environments where still only Composer 1 is available and we have less control over the installed version.

More information in the related Composer issue: composer/composer#9474

Any chance to rollback this PR from the 2.x branch and only drop support of Composer 2 in a new 3.x branch?

@mxr576 mxr576 changed the title Restore Composer 1x support in 2.x branch Restore Composer 1 support in the 2.x branch Nov 13, 2020
@johnbillion
Copy link

You should be able to address this yourself by using ^2 or 2.9.0 as the version for ergebnis/composer-normalize.

@johnbillion
Copy link

That said, yes this is a breaking change and should have been made in a major release, not a patch release.

@localheinz localheinz self-assigned this Dec 8, 2020
@localheinz
Copy link
Member

@mxr576

I will think about it, but as an alternative, consider updating composer in your build environments.

@localheinz
Copy link
Member

@johnbillion

It's not a breaking change, see #597, and in particular, 5413856#diff-d2ab9925cad7eac58e0ff4cc0d251a937ecf49e4b6bf57f8b95aab76648a9d34R21.

@johnbillion
Copy link

@localheinz Thanks for your work on this extension, it's very useful. Why do you not consider dropping support for Composer v1 as a breaking change?

@mxr576
Copy link
Contributor Author

mxr576 commented Dec 9, 2020

We do our best to get all envs on Composer 2, but as I wrote above, some environment are not in our control and think we are not the only one.

If Composer would know that it should not update to the latest minor/patch version of this library because it dropped Composer 2 support, this would not be an issue, but it does not know that and it won't, Composer maintainers have no interest to have this supported. (Which is fine.)
I am considering this BC break, because the build tool (aka Composer) cannot handle this change properly, if it would have happened in the major version that would be fine because the version constraint like ^2 or ^2.6 , etc would not allow Composer to upgrade to next major version.

(It is kinda like dropping support of a PHP version in a minor/patch version, which can be considered an edge case, BUT at least Composer can handle it, because it won't install the new version if the runtime environment has an older PHP version than what it is in the require section.)

@localheinz
Copy link
Member

@mxr576

I need to ask: have you considered sponsoring me to change my mind?

https://github.com/sponsors/localheinz

@mxr576
Copy link
Contributor Author

mxr576 commented Dec 14, 2020

Originally, I thought about code contribution if restoring Composer 1 compatibility is acceptable, but I'll consider the other option :)

@localheinz
Copy link
Member

@johnbillion @mxr576

Released as ergebnis/composer-normalize:2.13.0!

@mxr576
Copy link
Contributor Author

mxr576 commented Dec 30, 2020

Awesome :)
Thank you! 👍

@localheinz
Copy link
Member

@mxr576

You are welcome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants