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

Unpublishing leads to test system crashs (4.3.1/4.3.2 ) #99

Closed
leoselig opened this issue Mar 27, 2015 · 3 comments
Closed

Unpublishing leads to test system crashs (4.3.1/4.3.2 ) #99

leoselig opened this issue Mar 27, 2015 · 3 comments

Comments

@leoselig
Copy link

This refers to the issues deriving from #96
I'd like this to be an objective discussion (The unpublish note in the 4.3.2 release is not what I regard as objective)

If we have to expect that handling of the peerDependency again or any other SemVer violations this package simply has to be removed from our projects as it does not suite the requirements of a stable continous integration. That would be sad since it's a great plugin and we really enjoyed using it.

@leedm777
Copy link
Contributor

If we have to expect that handling of the peerDependency again or any other SemVer violations this package simply has to be removed from our projects as it does not suite the requirements of a stable continous integration.

@leoselig If you need that level of stability for your test dependencies, I highly recommend you use npm shrinkwrap --dev to control them. SemVer isn't perfect. Any package can accidentally introduce compatibility breaking changes. It even happened with chai.

In general, there's not a great way to handle accidental breaking changes. Often times, reverting the breaking change is itself a breaking change. So do you violate SemVer again? Or do you unpublish the offending version? Or do you revert the change as a major rev bump? (Chai did it the last way, BTW).

There's no perfect answer. You are between a rock and a hard place, and you're gonna break some people. As a maintainer, you use your best judgement and hope you don't get too much grief for it.

@leoselig
Copy link
Author

Thanks for the answer
I totally agree with you, trusting SenVer to keep your system stable is risky - I think I actually have to reconsider the strategy there
However, npm shrinkwrap wouldn't have worked in this case as far as I understand since the most important issue here that two versions where unpublished
I think against the latter there is actually no realistic protection which us why unpublish is strongly prohibited and requires a force flag

@keithamus
Copy link
Member

Just happened upon this. The breaking change in Chai 1.10.0 was entirely my fault, and I apologise to anyone who had trouble by this. I also handled the transition badly, it took too long to fix between 1.10.0 and 2.0.0, so once again, I apologise.

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

No branches or pull requests

3 participants