Discuss: Release version 1.0.0 and manage consumer breaking version expectations

[seanmakesgames]

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]

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]

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.

[seanmakesgames]

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