Skip to content

Conversation

@github-actions
Copy link
Contributor

This pull request prepares new gem releases for the following gems:

  • opentelemetry-api 2.0.0 (was 1.6.0)
  • opentelemetry-logs-sdk 0.4.0 (was 0.3.0)

For each gem, this pull request modifies the gem version and provides an initial changelog entry based on conventional commit messages. You can edit these changes before merging, to release a different version or to alter the changelog text.

  • To confirm this release, merge this pull request, ensuring the "release: pending" label is set. The release script will trigger automatically on merge.
  • To abort this release, close this pull request without merging.

The generated changelog entries have been copied below:


opentelemetry-api

v2.0.0 / 2025-08-26

  • BREAKING CHANGE: Remove Span APIs for attributes and events

  • FIXED: Remove Span APIs for attributes and events


opentelemetry-logs-sdk

v0.4.0 / 2025-08-26

  • BREAKING CHANGE: Add OTEL_LOGRECORD_ATTRIBUTE_* env vars. Remove OTEL_LOG_RECORD_ATTRIBUTE_* env vars.

  • ADDED: Add OTEL_LOGRECORD_ATTRIBUTE_* env vars. Remove OTEL_LOG_RECORD_ATTRIBUTE_* env vars.

* opentelemetry-api 2.0.0 (was 1.6.0)
* opentelemetry-logs-sdk 0.4.0 (was 0.3.0)
@kaylareopelle
Copy link
Contributor

Removing the #attributes and #events methods from the API gem is a breaking change according to semver. Before I release the API gem, I want to make sure no one opposes this bump.

@open-telemetry/ruby-maintainers, what do you think?

If I haven't heard anything, I'll release Thursday, 4 September.

@github-actions
Copy link
Contributor Author

WARNING: An additional commit was added while this release PR was open.
You may need to add to the changelog, or close this PR and prepare a new one.

Commit link: 463ef11

Message:
This PR corrects the spec-compliance of API Tracer.start_span. (#1905)

The spec states:

The API MUST return a non-recording Span with the SpanContext in the
parent Context (whether explicitly given or implicit current). If the
Span in the parent Context is already non-recording, it SHOULD be
returned directly without instantiating a new Span. If the parent
Context contains no Span, an empty non-recording Span MUST be returned
instead (i.e., having a SpanContext with all-zero Span and Trace IDs,
empty Tracestate, and unsampled TraceFlags).

With new tests that match the spec, the current implementation fails
with:

non-recording span with the parent span context if the parent span is
recording [test/opentelemetry/trace/tracer_test.rb:97]: Expected
@context=#<OpenTelemetry::Trace::SpanContext:0x0000000120e17140
@trace_id="E\xC6d\xD5S+h\x8B\xC6u\xE6\xD5\ePQ\xDD",
@span_id="\xE2\xB3\x01\x99\xEC\xA0\xC1\x81",
@trace_flags=#<OpenTelemetry::Trace::TraceFlags:0x00000001052a50c0
@flags=0>,
@tracestate=#<OpenTelemetry::Trace::Tracestate:0x000000012085fdd8
@hash={}>, @remote=false>> to not be equal to
@context=#<OpenTelemetry::Trace::SpanContext:0x0000000120e17140
@trace_id="E\xC6d\xD5S+h\x8B\xC6u\xE6\xD5\ePQ\xDD",
@span_id="\xE2\xB3\x01\x99\xEC\xA0\xC1\x81",
@trace_flags=#<OpenTelemetry::Trace::TraceFlags:0x00000001052a50c0
@flags=0>,
@tracestate=#<OpenTelemetry::Trace::Tracestate:0x000000012085fdd8
@hash={}>, @remote=false>>. ```

The new implementation correctly passes this test (and the old tests).
Shopify has been running with a similar patch in production for several
years, based on a belief that the spec was incorrect - instead the
_implementation_ was wrong.

@github-actions
Copy link
Contributor Author

github-actions bot commented Sep 2, 2025

WARNING: An additional commit was added while this release PR was open.
You may need to add to the changelog, or close this PR and prepare a new one.

Commit link: 7f5db11

Message:
fix: use mapping scale outside rescale logic (#1891)

  • fix: use mapping scale

  • add test case


Co-authored-by: Kayla Reopelle 87386821+kaylareopelle@users.noreply.github.com

@fbogsany
Copy link
Contributor

fbogsany commented Sep 5, 2025

I'm not a huge fan of the bump to 2.0.0. It is technically correct, but I wonder if it would be better to retract (somehow) the API version with the incorrectly added methods?

Swift and Javascript recently bumped their versions to 2.0.0, but those appear to contain major changes, including removal of deprecated APIs. Bumping to 2.0.0 feels like a major event, and it would be disappointing to do so "by accident".

A particular concern is the API support guarantee required by OpenTelemetry:

Major versions of the API MUST be supported for a minimum of three years after the release of the next major API version.

3 years is a long time to support a non-spec-conforming API version.

Copy link
Contributor

@fbogsany fbogsany left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See previous comment. I'd prefer to "retract" the previously released, non-spec-conforming API version and keep the 2.0.0 bump for a true major release.

@github-actions
Copy link
Contributor Author

github-actions bot commented Sep 5, 2025

WARNING: An additional commit was added while this release PR was open.
You may need to add to the changelog, or close this PR and prepare a new one.

Commit link: a6ce85b

Message:
feat: add record_exception option for in_span (#1911)

  • feat: add record_exception option for in_span

@github-actions
Copy link
Contributor Author

WARNING: An additional commit was added while this release PR was open.
You may need to add to the changelog, or close this PR and prepare a new one.

Commit link: 0b05b28

Message:
chore: remove references to batch processor (#1915)

@github-actions
Copy link
Contributor Author

WARNING: An additional commit was added while this release PR was open.
You may need to add to the changelog, or close this PR and prepare a new one.

Commit link: d8d8f98

Message:
chore: regenerate from opentelemetry-proto v1.8.0 (#1921)

  • chore: regenerate from opentelemetry-proto v1.8.0

  • Update exporter/otlp/Rakefile

Co-authored-by: Robert robertlaurin@users.noreply.github.com


Co-authored-by: Robert robertlaurin@users.noreply.github.com

@kaylareopelle
Copy link
Contributor

@fbogsany - sorry for missing the comments on this PR. I'm not sure what our options are to retract. I'll ask around in the OTel space and see if anyone else has an example of that.

@github-actions
Copy link
Contributor Author

WARNING: An additional commit was added while this release PR was open.
You may need to add to the changelog, or close this PR and prepare a new one.

Commit link: 1f4f85e

Message:
feat(semconv): update to v1.25 in a non-breaking way (#1651)

  • use v1.10-compat semconvgen to write deprecation notices

  • update semconv rake targets and templates for v1.26

  • pull from the new semconv repo

  • update jinja2 template for the new structure of convention data

  • stable semconv names will appear in OpenTelemetry::SemanticConventions
    while all semconv names (experimental, deprecated, stable, etc) appear
    in OpenTelemetry::SemanticCandidates

    • This maps to what other langs (Java, Python, JS) are putting into
      "Incubating" modules. We opted for "candidates" because
      OpenTelemetry::SemanticConventions::Incubating::... was getting
      too long and OpenTelemetry::SemanticIncubating didn't make much
      sense.
  • generate a module per root semconv namespace to make navigating docs
    more focused and to decrease the number of constants loaded when
    using more precise requires in downstream code

  • generates only attribute name constants and to an attributes subfolder
    to prepare for metric name constants to be generated to metrics
    subfolders, also for decreasing the scope of what gets loaded when
    downstream instrumentation requires these constants

Co-authored-by: Kayla Reopelle (she/her) 87386821+kaylareopelle@users.noreply.github.com

  • the code generated

  • add ability to exclude specific attrs from code gen

Because converting to SCREAMING_SNAKE_CASE cannot distinguish
between ...

screaming.snake_case

... and ...

screaming.snake.case

So, like other languages, ignore the deprecated messaging.client_id in
favor of its replacement and let backends deal with the changed attr
name.

  • reference the full name in the deprecation notice toward stable

  • test that constants are available in candidates

    277 runs, 500 assertions, 26 failures, 0 errors, 0 skips

Apparently there are some kinks to work out.

  • generate v1.25 semconv

There's naming hijinks in the db.* namespace I would like to avoid in
this first effort to bring semconv up-to-recent-date.

  • add/expand doc comments on top-level modules

Explain the auto-generated situation.

  • correct deprecation notices for several old names

The v1.10 names whose comments were updated in this commit were renamed
or removed in version 1.11-1.25. Made note of their replacements or that
their use should be dropped.

Removed test for one-to-one matching of 1.10 constants to 1.25 "all"
constants. That will never pass without updating the source semconv YAML
to add back the missing names with dep notices. I believe our dep notes
will suffice and we won't auto-generate Resource or Trace again.

  • gitignore semconv repo clone; rake improvements

  • Move to a tmp/ dir and ignore that.

  • Update the git commands to be able to reuse one directory for
    the repo working copy, just update what's needed for a different
    tag between iterations. (Generally only an improvement for dev envs.)

  • Use sh() for shell commands so that tasks fail if their commands fail.

  • Appease Rubocop.

  • typo/grammar corrections

Co-authored-by: Kayla Reopelle 87386821+kaylareopelle@users.noreply.github.com

  • adds kramdown to dev dependencies

Yard's default use of the rdoc markdown provider was choking on links
containing codeblocks, for example: ENV. These
style links are pretty popular in the text details provided with semconv
attributes.

Let's switch to kramdown which is a markdown parser and
renderer that:

  • can handle inline code blocks inside a link anchor

  • is pure Ruby (no C extensions) so works with JRuby

  • reorg module namespaces

  • out with Candidates, we're using Incubating like most other SIGs

  • shorten the namespace to SemConv

  • do not provide an all-in-one rollup require for all namespaces;
    downstream users must directly require the namespaces that they use

  • attributes that are templates (prefixes, really, for the moment) are
    generated as lambdas with _LAMBDA appended to their name; users must
    call that lambda with a key for the template to return the attribute
    name string

  • semconv 1.26 with weaver

With multiple template entries in weaver.yaml, code generation for
stable and incubating can be performed in one invocation of the docker
image. Rakefile targets trimmed down in light of that.

  • generate separate attrs and metrics files

Each root namespace gets separate attributes and metrics files.

Include examples of possible values for attributes.

Include a usage example of the template attributes as lambdas.

Fix links in doc comments referencing stable constants.

Co-authored-by: Hannah Ramadan hannahramadan@users.noreply.github.com
Co-authored-by: Kayla Reopelle kaylareopelle@users.noreply.github.com

  • generate rollup/barrel requires for each root namespace

  • extract clean of generated code into separate task

  • appease Rubocop

  • Layout/HeredocIndentation: Use 2 spaces for indentation in a
    heredoc.

  • Style/StringLiterals: Prefer single-quoted strings when you don't
    need string interpolation or special symbols.

  • Style/StringConcatenation: Prefer string interpolation to string
    concatenation.

    • ... except we don't want interpolation; we want to join pathname
      components with the correct separator for the operating system. So
      we'll use Pathname.join explicitly instead of Pathname's :+ operator
      so Rubocop doesn't think we're concatonating strings.
  • appease Rubocop

  • Style/RedundantCurrentDirectoryInPath: Remove the redundant
    current directory path

  • Style/RedundantFileExtensionInRequire: Redundant .rb file
    extension detected.

  • correct yard-doc refs to new short namespaces

  • Update Rakefile, tests, Gemfile

  • Bump constants to 1.36.0

  • appease Rubocop

Bundler/OrderedGems: Gems should be sorted in an alphabetical order within their section of the Gemfile.

Minitest/EmptyLineBeforeAssertionMethods: Add empty line before assertion.

Co-authored-by: Kayla Reopelle 87386821+kaylareopelle@users.noreply.github.com


Co-authored-by: Kayla Reopelle (she/her) 87386821+kaylareopelle@users.noreply.github.com
Co-authored-by: Hannah Ramadan hannahramadan@users.noreply.github.com
Co-authored-by: Kayla Reopelle kaylareopelle@users.noreply.github.com
Co-authored-by: Kayla Reopelle kreopelle@newrelic.com

@github-actions
Copy link
Contributor Author

WARNING: An additional commit was added while this release PR was open.
You may need to add to the changelog, or close this PR and prepare a new one.

Commit link: 3d82438

Message:
feat(utilities): create method for returning timestamp in nanoseconds (#1910)

Co-authored-by: Kayla Reopelle 87386821+kaylareopelle@users.noreply.github.com

@github-actions
Copy link
Contributor Author

WARNING: An additional commit was added while this release PR was open.
You may need to add to the changelog, or close this PR and prepare a new one.

Commit link: 75c8a39

Message:
feat: add span flags support for isRemote property (#1917)

  • feat(otlp-exporter): add span flags support for isRemote property

This commit implements the missing isRemote flag functionality in the Ruby
OpenTelemetry SDK's OTLP exporter, bringing it to feature parity with Go,
Python, PHP, and JavaScript SDKs.

Changes:

  • Add span flags constants matching OTLP specification (0x100, 0x200)
  • Implement build_span_flags method following OTLP spec
  • Extend SpanData to include parent_span_context field
  • Update span creation to store parent span context
  • Modify OTLP exporter to set flags for both spans and links
  • Update protobuf definitions to include flags field
  • Add comprehensive test coverage for all scenarios

The implementation follows the exact same pattern as other OpenTelemetry
SDKs, ensuring consistency across language implementations.

Flag values:

  • Local context: 0x100 (SPAN_FLAGS_CONTEXT_HAS_IS_REMOTE_MASK)
  • Remote context: 0x300 (HAS_IS_REMOTE_MASK | IS_REMOTE_MASK)

Fixes: Missing span flags support in OTLP exporter
Resolves: Feature parity with other OpenTelemetry SDKs

  • chore: updated changelog PR number

  • chore: added passing of parent_span_is_remote boolean in place of parent_span_context

  • fix: move isRemote implementation to correct production exporter

  • Revert changes from exporter/otlp-common (incomplete refactoring)
  • Remove span_flags.rb and tests from otlp-common
  • Add span_flags.rb to correct location in exporter/otlp
  • Implementation now in production exporter/otlp/lib/opentelemetry/exporter/otlp/exporter.rb

This addresses reviewer feedback that the common.rb file was not the production version.

  • refactor: improve build_span_flags function based on reviewer feedback
  • Remove default value for base_flags parameter (make it required)
  • Combine flag initialization into single line for better conciseness
  • Maintains same functionality while improving code clarity

Addresses reviewer suggestion for cleaner, more explicit function signature.

  • refactor: remove intermediate variable assignment in as_otlp_span
  • Remove span variable assignment and use .tap method instead
  • More concise code while maintaining same functionality
  • Addresses reviewer suggestion for cleaner code structure

The .tap method allows us to set the flags field and return the span
object in a single expression, eliminating the need for an intermediate variable.

  • refactor: pass flags directly as named argument to Span.new
  • Remove .tap method and pass flags: as named argument to Span.new constructor
  • More concise and cleaner code structure
  • Addresses reviewer suggestion for direct parameter passing

This eliminates the need for separate span.flags assignment and makes
the code more readable by setting all span properties in one place.

  • refactor: pass flags directly as named argument to Link.new
  • Remove intermediate link_proto variable assignment
  • Pass flags: as named argument directly to Link.new constructor
  • Apply same pattern as span creation for consistency
  • More concise and cleaner code structure

This completes the refactoring to pass flags directly in constructors
for both spans and links, eliminating separate assignment steps.

  • chore: implemented changes in expected file and improved code post review

  • fix: fix for failing test cases

  • fix: moved constants to a suitable location

  • failing test changes

  • chore: delete manual constants for span_flags and use the latest from the protobuf updates for the SDK

  • fix: added fix for workflow failing tests

  • fix: failing workflows

  • fix: replace magic number with SAMPLED constant

  • fix: all robocop offenses

  • fix: update base_flags_int and test objects

  • fix: do not pass integers to build_span_flags

  • chore: removed changelog


Co-authored-by: Kayla Reopelle 87386821+kaylareopelle@users.noreply.github.com

@fbogsany fbogsany closed this Sep 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release: pending Automated release is pending

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants