If you look at lots of popular OSS gems (like rails), you will eventually see conditional checks on framework version, language version, platform, etc. I think this blog post is supposed to be rage bait, but they’re kinda just doing a practical, straightforward extension of a huge complex framework, how else are you supposed to do that if the bits you need are not extensible? You can either fight to get the extensibility into upstream, or add the conditionals for if/when the undocumented private behavior changes.
I would use semantic versioning on dependencies here instead of forcing yet another piece of runtime code on already overburdened rails apps (ESPECIALLY initializers…). Pin yourself to the major/minor version of action_whatever with the signature you need, this is what semantic versioning is for. Maybe once you need your one gem to support many versions of the flaky upstream dependency, you add the runtime conditionals like I mentioned above.
But this is a private method, so its signature/behavior can change even in a patch version, right? If it were public, enforcing the minor version would be okay
Yeah exactly, so I guess you would need to pin pretty hard, which sounds impractical. Agree about public, minor, for sure (and wouldn’t be TOO surprised if even minor/patch broke things)
If we’re abiding by Semver (which I think most Ruby gems do), a backwards-incompatible public API change must be accompanied with a major version bump. Changing the implementation (which could include changing the interface of a private method) could be done in a minor or patch version. The goal of this is to enable you to still confidently upgrade non-major versions without worrying about changes. However, there are still gotches, IMO.
The only thing with this is it doesn’t protect you from method semantics changing. When having to use gem internals, I have historically used an exact gem version assertion with a note to make sure nothing has changed.
If you look at lots of popular OSS gems (like rails), you will eventually see conditional checks on framework version, language version, platform, etc. I think this blog post is supposed to be rage bait, but they’re kinda just doing a practical, straightforward extension of a huge complex framework, how else are you supposed to do that if the bits you need are not extensible? You can either fight to get the extensibility into upstream, or add the conditionals for if/when the undocumented private behavior changes.
I would use semantic versioning on dependencies here instead of forcing yet another piece of runtime code on already overburdened rails apps (ESPECIALLY initializers…). Pin yourself to the major/minor version of action_whatever with the signature you need, this is what semantic versioning is for. Maybe once you need your one gem to support many versions of the flaky upstream dependency, you add the runtime conditionals like I mentioned above.
But this is a private method, so its signature/behavior can change even in a patch version, right? If it were public, enforcing the minor version would be okay
Yeah exactly, so I guess you would need to pin pretty hard, which sounds impractical. Agree about public, minor, for sure (and wouldn’t be TOO surprised if even minor/patch broke things)
How is this any different than a public method which also may change at any time?
If we’re abiding by Semver (which I think most Ruby gems do), a backwards-incompatible public API change must be accompanied with a major version bump. Changing the implementation (which could include changing the interface of a private method) could be done in a minor or patch version. The goal of this is to enable you to still confidently upgrade non-major versions without worrying about changes. However, there are still gotches, IMO.
The only thing with this is it doesn’t protect you from method semantics changing. When having to use gem internals, I have historically used an exact gem version assertion with a note to make sure nothing has changed.