ruby
Add a CI job for SDoc
It'll prevent introducing breaking changes for SDoc.
See also: https://github.com/ruby/rdoc/pull/1304#issuecomment-2749251458
I understand the reasoning but I'm not sure if it's a good solution.
sdoc (and some other projects using rdoc) have various levels of patches on rdoc. If we need to avoid breaking them, it'll dramatically limit our ability to improve rdoc's codebase. For example, I think we should do #1309 even if it breaks sdoc as Store should be considered private.
And even if we think changes like #1309 is breaking and will release it with a major version bump, it'd still break the job nonetheless until 1) we cut the release, and 2) sdoc adopts the version and update its codebase for it. And before both of those happens we'd just have a broken CI.
Sure, we may say it'd be an optional job that's allowed to be broken. But from my experience those jobs will always be ignored and removed after a while as the value of maintaining it is low.
A more common, and maybe effective approach, would be for sdoc to run CI against the latest rdoc and provide feedback close to when the changes are merged.
Things could still break, but ideally we'll catch and improve most of them before releases.
SDoc is broken again at https://github.com/ruby/rdoc/pull/1315#issuecomment-3245877090
CI with SDoc is easy to our first step. I know we need to more time to develop incompatible changes for SDoc by that CI. But It's helpful for finding to unknown issues for SDoc.
@hsbt Thanks for raising this but I worked with Rafael and it's not broken again 😅 The context is: SDoc was broken by my changes, which I worked with Jonathan to address, and they're on SDoc main since months ago. But because various reasons, they can't use the latest SDoc main, so they saw the same compatibility issues again when trying to use other branches. And I believe Rafael has addressed them.
I'm fine with setting up the CI with SDoc now, but it wouldn't have helped the latest issues it saw anyway.
@st0012 Thanks for your explanation 👌 That's not strong opinion. Let's explore better ways forward with rdoc and sdoc.