Forgive me for any possibly misplaced concerns, I’m speaking the first thought that came to my mind while reading this:
How does upstream plan to prevent a Python 2/3 Perl5/6 situation with that?
I understand that our case is already quite distinct nowadays; comparing it to Perl is already really pushing it, and Python is still far off… as in our case OCaml 4/5 would be very much compatible languages (down to the majority of internal runtime function names and the stub API, and aside from the use of multicore-specific libs or unexposed internals)… so there should be less stubbornness making the switch from the community’s side…
but without a clear deprecation date, and as OCaml 5 evolves and collects more features, I worry about that gap growing, and having to eventually ask “Are you on OCaml 4 or 5? Is this library compatible with OCaml 5? etc…”, more importantly the possible divide, doesn’t sound like an attractive idea.
Reassurance, It’s very likely the maintainers have already thought about the implications of this, so I wonder if you’d like to comment on whether a plan exists to prevent that situation… If it’s not desirable to begin with… Or on how many more ways we’re distinct from those languages back in their time of flux. Of course with the sequential glaciation and the release of 4.14.0 in advance help alleviate this, but Python 2 was feature-frozen for 10 years too.