Misc #21928: Prism backport handling

• Status: Open
• Assignee: prism

[Earlopain (Earlopain _)]

https://bugs.ruby-lang.org/issues/21927 got marked for backport for 4.0 and 3.4. It's a trivial fix but since prism is a gem, ruby should contain a released version of prism only.

3.4 in particular currently contains prism 1.5.2. Backporting to that version would require at least two changes in ruby/ruby because of changes in prism itself. So it is not as easy as just tool/sync_default_gems. Currently the practise has been to just backport the lastest prism version but personally I don't think that is sustainable. At best it causes more work than necessary and at worst you get fresh new bugs in what is supposed to be a stable ruby release. https://github.com/ruby/prism/pull/3231 is a good example of something that should not be backported to all maintained ruby versions when it gets merged.

I propose to maintain stable branches for prism. Branch maintainers can simply cherry-pick what they think should be backported and prism takes care of releasing the appropriate versions, branched from the version that the stable ruby version originally shipped with.

As far as I'm aware, that's also the strategy other gems go with. It happens less frequent now that many gems are no longer standard gems but openssl for example has branches for this purpose https://github.com/ruby/openssl/branches. I'm not sure how it handles versions, some gems I see do 1.2.3.4 which doesn't exactly follow semver, but it should possible to do it by following semver.

What do you think @kddnewton (Kevin Newton)? I know that so far you've wanted to do the latest stable version but I think prism is too intertwined with ruby itself for the current approach. Especially now that there are two stable branches that ship with prism it doesn't get easier.

Specifically for the currently released versions, we can branch from 1.5.2 and 1.8.0, simply increasing the patch version since there is no conflict with later released versions. For ruby 4.1 we'd have to take care to acomodate this though.

[Earlopain (Earlopain _)]

• Description updated (diff)