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

1.0 release? #223

Open
novemberborn opened this issue Aug 27, 2018 · 7 comments
Open

1.0 release? #223

novemberborn opened this issue Aug 27, 2018 · 7 comments

Comments

@novemberborn
Copy link

Shipping a 1.0 release will make it easier for different projects to end up with the same instance of source-map-support (by relying on dependency deduplication). This would lessen the impact of #200.

@LinusU
Copy link
Collaborator

LinusU commented Aug 27, 2018

While it would indeed be nice with an 1.0 version, wouldn't it just make that specific problem even worse? Instead of libraries being divided on 0.4.x and 0.5.x, there would then be 3 different ranges (0.4.x, 0.5.x, 1.x.x)?

Bumping @babel/register to ^0.5.0 would fix the problem with Babel and AVA?

@novemberborn
Copy link
Author

Bumping @babel/register to ^0.5.0 would fix the problem with Babel and AVA?

Yes, until there's a 0.6.0. At least with a 1.0 release you can ship new features without requiring updates in dependents.

@LinusU
Copy link
Collaborator

LinusU commented Aug 27, 2018

Ah, I'm currently shipping both features and patches in the patch bump, and breaking changes in the minor bump, since that is how Npm seems to follow the 0.x semver range. So a 0.6.0 would be the equivalent to 2.0.0 if we switch to 1.0 now.

Still, I think 1.x is a good idea.

It could be nice to wait for source-map to release an 1.0 though, and then we could upgrade to that (which will be a breaking change anyhow) and release our 1.0.

@novemberborn
Copy link
Author

novemberborn commented Aug 27, 2018

Still, I think 1.x is a good idea.

Yay!

It could be nice to wait for source-map to release an 1.0 though, and then we could upgrade to that (which will be a breaking change anyhow) and release our 1.0.

The problem is that source-map has dropped support for Node.js 6, which isn't palatable to AVA or (I strongly suspect) Babel until April next year, when it loses LTS status.

Worst case we need to republish source-map@0.6 so both versions can be depended on, and then select the correct version based on the runtime.

@LinusU
Copy link
Collaborator

LinusU commented Aug 27, 2018

Hmm, just realised that we cannot upgrade source-map at all currently, since they only have an async api now 🤔

@novemberborn
Copy link
Author

Oh dear.

It might be good to unite all source-map related packages into one organization, which could make it easier to evolve them with each others interests in mind. At this point I think source-map needs to be forked to have a synchronous implementation…

@joebowbeer
Copy link

joebowbeer commented Feb 14, 2020

This needs a 1.0.

None of the versions lower than one can be assumed to be compatible, so no hoisting is possible.

To help developers who rely on your code, we recommend starting your package version at 1.0.0 - About Semantic Versioning

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