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

Discuss: Release version 1.0.0 and manage consumer breaking version expectations #276

Open
seanmakesgames opened this issue May 23, 2023 · 3 comments

Comments

@seanmakesgames
Copy link
Contributor

We currently manage versions in 0.* releases which is semver compliant, but doesn't give any guarantees on compat to our consumers.

I feel like it's been many years since we released a breaking change that was not a v8 / node version update and I think we can have a version number model that at least gives a decent confidence in breaking / not breaking for consumers.

@tisba
Copy link
Collaborator

tisba commented May 26, 2023

I like the idea! Might be a little arbitrary, but if we can get to node/V8 18.16.x (#277), that might be an opportunity to call it a 1.0.0, because node 18 is LTS.

@lloeki
Copy link
Collaborator

lloeki commented May 26, 2023

but doesn't give any guarantees on compat to our consumers.

Typically the common expectation would be that 0.x.y offsets semver: x is like major (so, breaking) and y is like minor+patch (so, not breaking).

call it a 1.0.0, because node 18 is LTS.

I'd aim for node 20, which will be the next to enter LTS on 2023-10-24. That way we unroll the catch up plan as smoothly as possible, without constraint, then can start to claim stability on solid ground.

To me 1.0 is not just about external API stability, it's also about being able to properly support such stability internally and clearly and reliably enable users and contributors (contributing guide, support policy, reliable CI, merging rules, branching model...), and I feel the current state is lacking in these departments.

@lloeki lloeki mentioned this issue May 26, 2023
37 tasks
@seanmakesgames
Copy link
Contributor Author

Agreed, @lloeki - We should have the framework in place for a healthy package. We have most of these rules and practices, just need to write them down.
CI upgrades need to be done. I'm on board for waiting for those things before cutting a 1.0 --

Sounds like we have a plan. Going to tag / flag some issues that seem related:
rubyjs/libv8-node#44
rubyjs/libv8-node#42
rubyjs/libv8-node#39
rubyjs/libv8-node#7

@tisba tisba mentioned this issue Jun 3, 2023
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