KOSAKI Motohiro <kosaki.motohiro / gmail.com> wrote:
> >> I agree the compatibility problem.
> >> I hope the migration path, the magic comment and command line option,
> >> mitigate the problem enough.
> >> Current code can work for Ruby 3.0 with trivial one line addition:
> >> "# frozen-string-literal: false".
> >> If the performance improvement can be discarded, even the addition is unnecessary.
> >> The only necessity is the command line option, --disable-frozen-string-literal.
> >
> > I worry those options will be disappeared in future versions. I need to make sure that the option will be guaranteed to remain exist in future versions.
> 
> Ruby is a open source project. You can contribute for a compatibility.

Basically, that means showing up to the mailing list to say "no" to
incompatible changes.  I guess I've done my part :)

Anyways, further points:

* magic comment should be a stopgap until VM can optimize transparently

* The command-line option is pointless.  It is incovenient and
  easy to leave out, and also breaks if used with shebang for scripts
  which are meant to work with olld and new versions.

That said, maybe the C API can and probably should change more in 3.0
with adequate deprecation warnings (2-3 years at least).

> > As a person who is responsible managing for many Ruby-based enterprise products, I really care about the compatibility. It was a nightmare to migrate our 1.8.7 codes to 1.9, because of many small incompatiblity in the release. Even small incompatibilities, it's a real burden for users if there are many...
> 
> I really don't understand why you can think other rubyist think a
> compatibility isn't important.

History; 1.8 -> 1.9 broke working code.  Several sysadmins I know
(not really programmers) abandoned it and went back to Perl5.