Adjust gem version management to have .dev version in master

[p-datadog]

What does this PR do?

Adjusts the code and scripts to have the gem version in master be suffixed with .dev during development.

_ Alters lib/datadog/version.rb to specify .dev suffix. This should be the "steady state" unless we are actively releasing.

This change means that when anyone builds the gem from master, they would get a version number like 2.23.0.dev. Currently the version would be 2.23.0 which is wrong - we haven't released 2.23.0 yet. The prematurity of release version appearing in our sources is, for example, causing the current issues/confusion with system tests.

_ Adds error checking and a diagnostic report to

dd-trace-rb/.gitlab/patch_gem_version.sh

Lines 33 to 34 in 895d80e

	sed lib/datadog/version.rb -i -e "s/^\([\t ]*PRE\) *= */\1 = \'${PRE}\' # /"
	sed lib/datadog/version.rb -i -e "s/^\([\t ]*BUILD\) *= */\1 = \'${BUILD}\' # /"

. No behavior changes in this script. I tested it locally after providing the 4 parameters (which could be any junk values). The script already handles the existing version having the .dev suffix as far as I can tell.

_ As far as I can tell no action is needed to go from 2.23.0.dev to 2.23.0 during release process. The version to release is specified manually and it's already 2.23.0, this will require no changes. I verified that the rake task used to bump the version works with the existing tree having the .dev suffix. This is called from

dd-trace-rb/.github/workflows/bump-gem-version.yml

Line 51 in 895d80e

bundle exec rake version:bump["${NEXT_VERSION}]"

.

_ The post-release version bump is confusing. I found https://github.com/DataDog/fast_castle/blob/main/dd-trace-rb/steps.rb#L389 but this does not create the pull request. I can't find where the PR is actually generated.

I adjusted

dd-trace-rb/.github/workflows/bump-gem-version.yml

Line 7 in 895d80e

description: Version to update to

to specify that normally those version numbers should have the .dev suffix, because the only time they wouldn't should (I think) be handled by the release process, as specified above.

Motivation:

Review of DataDog/system-tests#5799 + I think ST does not run our tests properly or I don't understand the versioning

Change log entry

None

Additional Notes:

The ST hackage was implemented in DataDog/system-tests#3022, it should not be needed with the changes in this PR (but possibly ST needs to be updated to deal with the Ruby version format of 2.23.0.dev instead of 2.23.0-dev that is common elsewhere).

How to test the change?
I tested all of the above mentioned scripts locally with various inputs

[datadog-official]

⚠️ Tests

⚠️ Warnings

🧪 1 Test failed

tests.parametric.test_process_discovery.Test_ProcessDiscovery.test_metadata_content_without_process_tags[library_env0, parametric-ruby] from system_tests_suite (Datadog)

AssertionError: assert Version('2.23.0-dev') == Version('2.23.1')
  Full diff:
  - Version('2.23.1')
  ?               ^
  + Version('2.23.0-dev')
  ?               ^^^^^

self = <tests.parametric.test_process_discovery.Test_ProcessDiscovery object at 0x7fd29683de50>
test_library = <utils.docker_fixtures._test_clients._test_client_parametric.ParametricTestClientApi object at 0x7fd29608c8f0>
library_env = {'DD_AGENT_HOST': 'localhost', 'DD_ENV': 'second-test', 'DD_EXPERIMENTAL_PROPAGATE_PROCESS_TAGS_ENABLED': 'false', 'DD_SERVICE': 'b', ...}
...

ℹ️ Info

❄️ No new flaky tests detected

🎯 Code Coverage
• Patch Coverage: 100.00%
• Total Coverage: 95.21% (-0.01%)

View detailed report

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: c05c07f | Docs | Datadog PR Page | Was this helpful? Give us feedback!}

[p-datadog]

This PR is failing system tests e.g. https://github.com/DataDog/dd-trace-rb/actions/runs/19868421868/job/56937408519?pr=5108 which expect the hacked version, maybe it needs to be merged after DataDog/system-tests#5799 or some other coordination is required.

[ivoanjo]

👍 We've slowly been moving in the direction of doing this, so I think it's time we rip-off the band-aids, and just fix whatever CI/tests need to be updated to match this change.

[ivoanjo]

Minor: Rather than an indication, should we make the rake task actually fail if it's not .dev?

[p-datadog]

I don't know if this would be OK...

[ivoanjo]

If it turns out to not be great, we can always undo it -- what's the worst thing that can happen if a rake task used to bump the version refuses to bump it?

[ivoanjo]

(You can say it was my fault 🤣 )

[p-datadog]

This comment is on a GH workflow change but you suggest changing the rake task. The rake task is used during release process where it's getting the version-to-be-released as the argument (e.g. 2.23.0), so that definitely cannot be constrained to dev only. Did you mean the rake task or the GH workflow restriction? For GH workflow I'd have to research how to do that.

[p-datadog]

Actually I thought the release bump was triggered from https://github.com/DataDog/fast_castle/blob/main/dd-trace-rb/steps.rb but I don't see where now, maybe I'm wrong on that too.

[ivoanjo]

Actually, it wasn't needed before, but we may need to adjust that. If you think about it, before, there was only 1 thing needed: previous version -> next version. Master would be all set for release.

Now due to this PR we'll have previous version -> next dev. We'll need to change fast_castle (or something else) to have next dev -> next version.

[pr-commenter]

Benchmarks

Benchmark execution time: 2025-12-04 14:34:41

Comparing candidate commit c05c07f in PR branch gem-version with baseline commit a684817 in branch master.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 44 metrics, 2 unstable metrics.