Repository navigation
Discuss: Release version 1.0.0 and manage consumer breaking version expectations #276
Description
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.
Activity
tisba commentedon 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 commentedon May 26, 2023
Typically the common expectation would be that
0.x.yoffsets semver:xis like major (so, breaking) andyis like minor+patch (so, not breaking).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.
seanmakesgames commentedon May 26, 2023
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