[Rfc-markdown] Old Rubies (Re: [Tools-discuss] kramdown-rfc2629 problems on MacOS Mojave)

[Carsten Bormann <[e-mail]>]

Hi Toerless,

You may want to know about the [e-mail] mailing list [1].

(Rfc-markdown readers: please do read on, this is not unimportant.)

Given that you have started the thread over on tools-discss, I’ll dual-post.

> On 2022-02-09, at 19:14, Toerless Eckert <[e-mail]> wrote:
> 
> /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/erb.rb:864:in `eval': (erb):107: multiple assignment in conditional (SyntaxError)

Right.  This is a regression that we introduced on 2021-11-25 while putting in the venue feature (PR #148); it was first released in 1.5.18 2021-11-29 AFAICT. 
(But see also below.)

> So i am using Mojave's very own ruby 2.3

BINGO.

> But i had recently new-installed Mojave and didn't have problems with even older MacOS versions.

So if whatever you had before was as ancient as Mojave’s Ruby is, you didn’t update your kramdown-rfc since November.  Shame on you.

But let me give a bit of context here.

                 .oOo.

## Context

kramdown-rfc's gemspec says:
  s.required_ruby_version = '>= 2.3.0'
Ruby 2.3.0 was released six years ago (2015-12-25).

The reason we try to reach so far back is that operating system
platforms often get shipped with Ruby versions that already were old
at first shipment, and don't update the version over the lifetime of
the operating system (e.g., bleeding-edge macOS Monterey still ships
with Ruby 2.6).  In particular, macOS High Sierra ships with a system
Ruby of version 2.3, which we still wanted to support.

We do recommend running kramdown-rfc with a recent Ruby, so the
considerations here are relevant only for those who do run it on the
System Ruby.

Interestingly now, from 2021-10-29 (1.5.13) to 2021-12-16 (1.5.24),
kramdown-rfc shipped with code that only parses successfully from Ruby
2.6 upwards.

So maybe backwards compatibility back to High Sierra's system Ruby is
not that important?  Or is the section of the user community that runs
system Ruby identical with the section that never updates kramdown-rfc
either?  There is not that much in terms of vulnerabilities that an
old Ruby version causes with kramdown-rfc, so there is no strong
incentive to upgrade, except maybe for the occasional warning with
ancient Rubies.

Back to the incident: Ruby 2.6.0 was released three years ago
(2018-12-15), so it is not surprising that this is a reasonable
baseline for most of us.  I only noticed the regression on a repo that
had an old Travis install that for some reason was still using Ruby 2.4.

So should we be more aggressive in requiring recent Ruby versions?

Every self-respecting Ruby programmer wants to use the updates Ruby
3.0 brought a year ago, but that update may still be a bit too
aggressive for some users.  For now, we would probably just move the
baseline up to 2.6, as we inadvertantly already did.

Similar considerations of course also apply to other tools, such as
the cddl tool.  I'd also be interested in learning from the battle
scars of IETFers having the equivalent problem with their tools
running on Python (Python 2 anyone?) or JavaScript (outside the
browser, which is pretty much force-updated these days).

                 .oOo.
## Plan

So here’s what I plan to do.  I’ll release a 1.5.26 with a quick fix for Ruby 2.3 in an hour or so (this also has other new features, so this will be fun).

Toerless: Since you now have volunteered to serve as the Ruby 2.3 guinea pig, you’ll tell me whether that fixes the problem immediately at hand.

But I do want to give up supporting Ruby 2.3 at some point.  The main reason is that we’d need a much more sophisticated testing strategy to avoid having these regressions over and over.  The new baseline will be 2.6 (as included as System Ruby since macOS Catalina, but the recommendation stands to install home-brew and a recent Ruby — we are at 3.1.0 now, BTW).

To provide data for deciding on the flag day, since 1.5.25, kramdown-rfc reports the Ruby version it was run under in the headers of the generated XML; I haven’t started mining that data yet.  But maybe that won’t be that useful, because people with ancient Rubies are likely to run ancient kramdown-rfcs, so I probably need to make a sample based on submission dates.  (I also can’t detect people who use kramdown-rfc and xml2rfc to generate plaintext and submit that.)

Grüße, Carsten

[1]: https://www.ietf.org/mailman/listinfo/rfc-markdown