[PROF-13303] Remove 3.5.0-preview1 and 4.0.0-preview3 headers and bump gem version to 3.5.0#24
Merged
Merged
Conversation
Now that 4.0.0 stable is out, we no longer need these outdated headers. I still left the 4.0.0-preview2 headers since dd-trace-rb CI is still, as of this writing, using them, but once we update it those should be cleaned up as well.
Why gem version 3.5 instead of [4.0.0](https://rubygems.org/gems/debase-ruby_core_source/versions) like upstream does? So the reason upstream moved to 4.0.0 is to match the Ruby version; e.g. before they shipped 4.0.0.preview2 and before that 3.4.1. But I think this numbering format does not make sense for us. Specifically, dd-trace-rb pulls in this gem in a format such as ```ruby spec.add_dependency 'datadog-ruby_core_source', '~> 3.4', '>= 3.4.2' ``` and thus regardless of you being on Ruby 2.5 or 4.0, you'll get the latest version of this gem. Coupling with upstream numbers is awkward because: * For preview Rubies, a release like "4.0.0.preview2" doesn't get picked up by bundler automatically, so we'd add manual toil to customers that want to test preview releases * We don't ship headers for every Ruby version. So what happens if we find out we need to add headers for Ruby 2.7.3 specifically? What release number do we use? 4.0.1? 4.0.0.2.7.3? Do we do a "patch release" from an older branch? But then how do we make sure the patch release gets picked up over a 4.0.0 release that has a bigger number but does not yet have the 2.7.3 headers? So for the time being I propose we do the following: * Decouple from upstream/ruby version schemes * Bump the minor version whenever we release support for a newer Ruby. That is, for Ruby 4.0 we'll bump to 3.5.0, for 4.1 it will be 3.6.0, etc In the end, I belive this is a two-way door decision -- e.g. nothing's stopping us from changing our minds, and e.g. going back to match upstream or other schemas in the future.
y9v
approved these changes
Jan 8, 2026
ivoanjo
added a commit
that referenced
this pull request
Jan 13, 2026
…em version to 3.5.1 **What does this PR do?** This PR fixes a bug in the "fuzzy" matching of headers to Ruby versions, where Ruby 4.0.1 would incorrectly fall back to 4.0.0-preview2 headers INSTEAD of 4.0.0 stable headers. It also bumps the gem version so we can get this fix out ASAP before we cause issues to customers upgrading to 4.0.1 and later. **Motivation:** Fix support for Ruby > 4.0.0. **Additional Notes:** This bug lay dormant for a long time, as usually we didn't ship at the same time preview/rc headers and stable headers. But because dd-trace-rb CI is still running on 4.0.0-preview2, we kept both this time and so the bug came and said hi. The issue boils down to `Gem::Version` treating any suffixes as non-stable versions (including the `p0`). Thus `4.0.0.preview2` > `4.0.0.p0` because between non-stable versions it sorts on string (and `preview` comes after `p0`); eliminating the useless prefix for stable Rubies avoids this. Interestingly, in #24 I mentioned that we had a slight sharp edge where `4.0.0-preview3` would fall back to `4.0.0-preview2` and that didn't work correctly; and this PR actually fixes that as a side-effect: `4.0.0-preview3` will now fall back to the stable headers, which is actually correct. **How to test the change?** Since the gem didn't previously have tests I bootstrapped some quickly so I could add test coverage for this change.
This was referenced Jan 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
This PR:
Removes the 3.5.0-preview1 and 4.0.0-preview3 headers
I still left the 4.0.0-preview2 headers since dd-trace-rb CI is still, as of this writing, using them, but once we update it those should be cleaned up as well
Bump gem version to 3.5 in preparation for release
Motivation:
Get the next release out for customers.
Additional Notes:
Why gem version 3.5 instead of 4.0.0 like upstream does?
So the reason upstream moved to 4.0.0 is to match the Ruby version; e.g. before they shipped 4.0.0.preview2 and before that 3.4.1.
But I think this numbering format does not make sense for us. Specifically, dd-trace-rb pulls in this gem in a format such as
and thus regardless of you being on Ruby 2.5 or 4.0, you'll get the latest version of this gem.
Coupling with upstream numbers is awkward because:
What release number do we use? 4.0.1? 4.0.0.2.7.3?
Do we do a "patch release" from an older branch? But then how do we make sure the patch release gets picked up over a 4.0.0 release that has a bigger number but does not yet have the 2.7.3 headers?
So for the time being I propose we do the following:
In the end, I belive this is a two-way door decision -- e.g. nothing's stopping us from changing our minds, and e.g. going back to match upstream or other schemas in the future.
How to test the change?
I manually tested locally that 4.0.0-preview2 still uses the correct headers and passes the test suite:
4.0.0 stable is fine:
...and 3.4.7 stable is fine:
Finally, this change does break 4.0.0-preview3 since it falls back to the preview2 headers:
But since we don't officially support preview versions that seems fine! If for any weird reason that I can't think of any user needs -preview3, it's still possible to pin to the 3.4.3 version of this gem to get the correct headers -- but we strongly recommend moving to 4.0.0 stable.