Brainstorming: backward compatibility policy #1485
Description
I would like to open a debate around what should be our compatibility policy guarantees for the future, and our approach to breaking changes. What we've done so far in practice, since 1.0, is to consider a breaking change any non backward-compatible change to the standard library API, to the language syntax or semantics (excluding explicitly primops), and in general making any currently valid program being invalid. That being said, we restricted ourselves to documented behavior, and excluded from the guarantee what were considered bugs or accidental behavior (which, let's be honest, is not very well defined and was more based on common sense an agreement in the team).
The goal if this issue is to iron out a more principled and well-defined backward compatibility policy, including:
- what is considered a backward-incompatible change precisely (both in surface and nature)
- what is our approach to bumping the major version number of Nickel. Is it ok to do so relatively regularly (e.g. Ocaml, GHC)? Should we try to stick to a very stable language (Rust)? Is it more to bump it if, although the new version brings incompatible changes, the migration is simple?
- should we have a Rust-like system of edition, to have "backward-incompatible change in disguise"? Or a middle ground, such as trying to provide an external, automated migration tool that rewrites your Nickel program (a bit less nice for users, but probably easier for us implementers)
Of course, there's already a lot of existing languages to take inspiration from, with various tradeoffs. Feel free to voice your opinion, and to mention good examples that you know of in other languages.