tmp-promise@2.1.0 contains a breaking change and should be republished as 3.0.0

[mbargiel]

The change introduced by #42 bumps the tmp dependencies from 0.1.0 to ^0.2.0.

tmp@0.2.0 actually contains a breaking change over tmp@0.1.0 which will affect consumers of tmp-promise since it is a pluggable wrapper that directly exposes tmp, so the proper version of tmp-promise should be 3.0.0 rather than 2.1.0.

An example of a breaking change is the use of tmp.dir({ dir: '/etc/arbitrary-path' }), which is no longer allowed in 0.2.0 (see raszi/node-tmp#250).

[benjamingr]

I will unpublish immediately and republish with an appropriate version number.

Apologies.

[benjamingr]

npm ERR! code E405
npm ERR! 405 Method Not Allowed - PUT https://registry.npmjs.org/tmp-promise/-rev/15-431df1ac349c08cd4b86be27db5e5bc8 - You can no longer unpublish this package.
npm ERR! Failed criteria:
npm ERR! has dependent packages in the registry
npm ERR!
npm ERR! Please deprecate it instead:
npm ERR! npm deprecate -f 'tmp-promise@2.1.0' "this package has been deprecated"
npm ERR! To learn more about our unpublish policies, see https://www.npmjs.com/policies/unpublish

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\benja\AppData\Roaming\npm-cache\_logs\2020-05-05T16_02_28_131Z-debug.log

[benjamingr]

Hey, I deprecated 2.1.0 with a warning and published 3.0.0.

I tested this locally and didn't run into the issue, if you can contribute a test to make sure I don't make this sort of mistake in the future I would appreciate it.

[benjamingr]

Would it be appropraite to publish a 2.2.0 using tmp ^0.1.0 ?

[mbargiel]

Thanks for reacting quickly! Don't worry about the mistake, it happens :)

Normally minor version bumps are backwards-compatible, but this is only true if the major version component is 1 or higher. When the major version component is 0, then minor version components convey the breaking nature of changes. That's a quirk of SemVer (Semantic Versioning).

if you can contribute a test to make sure I don't make this sort of mistake in the future I would appreciate it.

Versioning issues are pretty hard to guard against with automated tests, so unfortunately I don't really see what I could contribute. Normally I'd be happy to open a PR for this.

Would it be appropriate to publish a 2.2.0 using tmp ^0.1.0 ?

That's a good idea. I think you could republish the previous version (2.0.2) as 2.1.1 with a note saying it's reverting 2.1.0, which was yanked - that's pretty much how the SemVer spec recommends dealing with these versioning mistakes. With the deprecation notice for 2.1.0, that should cover any case of people using ^2.0.0 or similar.

[mbargiel]

Or if it's simpler, manually fix the dependency and set the version to 2.1.1 to have the same effect.

[benjamingr]

Hey, I published 2.1.1 that depends on 0.1.0 - I'm not too happy with this because 2.1.0 is still out there with the bad dependency but nothing I can do.

Thanks for the report and responsiveness and humble apologies 🙏

[mbargiel]

Don't worry about those in the wilds - either it'll work for the consumers of they'll be looking for a fix soon, and now they'll find it ;)