This is very much a known issue, though it’s probably only been noted on several non-obvious Talk posts.
Short version: hopefully not. I.e., I would hope most implementations were taking advantage of the SDK and the distro.properties file to manage their versions rather than manually building on top of the platform release. This is the model that we use for the RefApp.
More concerning, though, is ensuring things are running with the right version of the FHIR2 module. The FHIR2 module development cycle is a bit faster than the platform development cycle, so, e.g., the Platform 2.4.0 release bundles FHIR2 1.0.0, but O3 realistically probably requires at least FHIR2 1.2.2, i.e., the version running on openmrs-spa.org.
This is a bit of a difficult question. I don’t like releasing patch versions of the platform that have a breaking change. E.g., if we did a full release of, say, platform 2.3.6 with FHIR2, that would break things for anyone using 2.3.x and relying on the FHIR module, because the FHIR2 module is not backwards-compatible with the FHIR module (this is why it’s a separate module). The other alternative is to come up with some kind of tagged release thing so we have, e.g., platform-2.3.6 and platform-2.3.6-fhir2. That’s possible, but is a fair bit of work to setup and maintain (i.e., the CI pipelines need to be modified to handle that). Ultimately, this is why we only ever shipped FHIR2 by default with 2.4.
I outlined two options above. The “simple” thing (e.g., 2.3.6 with breaking changes) is quite low-effort other than verifying that the platform releases “took” and everything ended up where it was supposed to. If things break (those release builds can be finicky), it could take a couple of days to do that many releases, but realistically, its probably a few hours.
The more complex thing involves re-writing the CI plans and that’s probably a couple of hours of work on top of the same level of effort as above.