Discuss: Release version 1.0.0 and manage consumer breaking version expectations about mini_racer HOT 3 OPEN

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.

from mini_racer.

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.

from mini_racer.

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

from mini_racer.