chore(release): proposal for libdd-capabilities-impl, libdd-crashtracker, libdd-data-pipeline, li... - #2482
Merged
hoolioh merged 51 commits intoSep 8, 2026
Conversation
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
… bumps Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
…bumps Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Contributor
🔒 Cargo Deny Results📦
|
Contributor
📚 Documentation Check Results📦
|
Contributor
|
✅ All CI checks and tests passed. 🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: d5d98fd | Docs | View more details | Give us feedback! |
hoolioh
marked this pull request as ready for review
September 8, 2026 14:13
hoolioh
requested review from
danyal002 and
sameerank
and removed request for
a team
September 8, 2026 14:13
hoolioh
approved these changes
Sep 8, 2026
![datadog-datadog-prod-us1[bot]](https://avatars.githubusercontent.com/u/365230?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
The proposal gives libdd-ipc-macros version 1.0.1 after it adds a public macro API. SemVer requires version 1.1.0 for this additive feature.
🤖 Datadog Autotest · Commit d5d98fd · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest
| [package] | ||
| name = "libdd-ipc-macros" | ||
| version = "1.0.0" | ||
| version = "1.0.1" |
Contributor
There was a problem hiding this comment.
Consumers and release tools receive a feature release that has an incorrect patch label.
Assertion details
- Input: Publish libdd-ipc-macros after the addition of ClientType support, a generated client request enum, and public channel methods.
- Expected:
Set the version to 1.1.0. Update the changelog, lockfile, and libdd-ipc dependency to match. - Actual:
The proposal sets the crate version to 1.0.1.
Was this helpful? React 👍 or 👎
🤖 Datadog Autotest · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest · Open Bits AI session
Contributor
Author
Artifact Size Benchmark Reportaarch64-alpine-linux-musl
aarch64-unknown-linux-gnu
libdatadog-x64-windows
libdatadog-x86-windows
x86_64-alpine-linux-musl
x86_64-unknown-linux-gnu
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d5d98fd1b1
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| indexmap = "2.11" | ||
| libdd-alloc = { version = "1.0.0", path = "../libdd-alloc" } | ||
| libdd-common = { version = "5.2.0", path = "../libdd-common", default-features = false, features = ["reqwest", "test-utils"] } | ||
| libdd-common = { version = "6.0.0", path = "../libdd-common", default-features = false, features = ["reqwest", "test-utils"] } |
There was a problem hiding this comment.
When this release set is published, libdd-profiling remains at version 1.0.0 with no new release entry even though its normal dependency was rewritten from libdd-common 5 to 6. The proposal packaging workflow only includes crates whose own package version changed (.github/workflows/release-proposal-test.yml, lines 58-93), so consumers combining the newly released crates with the published profiling crate can resolve both libdd-common majors, creating the duplicate-package or symbol-incompatibility situation noted in the proposal warning. Give libdd-profiling the required major bump and include it in this release.
Useful? React with 👍 / 👎.
Comment on lines
+35
to
+36
| libdd-common = { path = "../libdd-common", version = "6.0.0", default-features = false } | ||
| libdd-trace-utils = { path = "../libdd-trace-utils", version = "12.0.0", optional = true } |
There was a problem hiding this comment.
This rewrites libdd-sampling's normal dependencies to the new major versions of both libdd-common and libdd-trace-utils, but leaves the crate at version 6.0.0 and outside the release set. Because the proposal packaging workflow selects only crates whose own version changed (.github/workflows/release-proposal-test.yml, lines 58-93), downstream users of sampling alongside the new releases can retain the published sampling package's old dependency graph and resolve duplicate libdd majors. Bump libdd-sampling to the next major and include it in the proposal.
Useful? React with 👍 / 👎.
hoolioh
merged commit Sep 8, 2026
7ffbbcb
into
release/libdd-capabilities-impl-14-more/20260908-130144
121 of 125 checks passed
hoolioh
deleted the
release-proposal/libdd-capabilities-impl-14-more/20260908-130144
branch
September 8, 2026 14:53
This was referenced Sep 11, 2026
gh-worker-dd-mergequeue-cf854d Bot
pushed a commit
that referenced
this pull request
Sep 21, 2026
#2508) # What does this PR do? Adds a `level_overrides` input to the release-proposal dispatch, so a wrong bump level can be corrected by re-running the workflow from the Actions tab instead of checking the proposal branch out and running cargo-release by hand. ``` level_overrides: libdd-capabilities=minor, libdd-ipc=major ``` `release-version-bumps.sh` gains `--level-overrides CRATE=LEVEL,...` and uses the given level for those crates instead of calling `semver-level.sh` — which is also where the run's time goes, so an overridden crate gets cheaper as well as corrected. It also records the dispatch inputs in an HTML comment at the top of the generated PR body: ```html <!-- release-proposal-inputs: {"crates":"libdd-capabilities-impl, libdd-ipc","main_start_ref":"","level_overrides":"libdd-capabilities=minor","bypass_standard_checks":false} --> ``` so a follow-up run can reconstruct them without an operator retyping the crate list. The second commit is unrelated to the feature and can be reviewed on its own: the `cargo-release` job installed its four tools with `taiki-e/cache-cargo-install-action`, which runs `cargo install` and caches the result. On the last dispatch those four steps cost **703s of the job's 3660s**, all cache misses. `pr-title-semver-check` installs two of the same tools with `taiki-e/install-action` in **77s**. Switched to install-action, and pinned all four — `cargo-release` and `git-cliff` were unpinned, which let the tools that choose version numbers and render changelogs drift under the workflow that cuts releases. # Motivation Reviewing release proposal #2482 turned up `libdd-capabilities` proposed as `patch` when its `http` requirement had moved from `^1` to `^1.1`. Fixing one crate's level meant a local checkout, a manual `cargo release version`, regenerating that crate's changelog, and a push — for a branch whose whole diff is `Cargo.toml` and `CHANGELOG.md` files. Overriding the *input* rather than patching the branch is the point: the cascade, the changelogs and the publication order are all recomputed from the corrected level, so a level raised to `major` can pull further crates into the release, which hand-editing the branch would miss. # Additional Notes - **Names are validated against the computed release set, not the `crates` input.** The crate you most often need to correct was never named in `crates` — in #2482, `libdd-capabilities`, `libdd-ipc-macros` and `libdd-tinybytes` were all pulled in transitively. A name that is not a candidate fails with the candidate list rather than silently shipping the computed level. - **`level_overrides` is carried in the inputs block** so successive corrections accumulate instead of the newest one reverting the last. That is a correctness requirement, not a convenience. - **The block is `-->`-proof.** `>` is escaped to the JSON sequence `\u003e`, which decodes to the same character for a parser but can no longer terminate the HTML comment. `main_start_ref` is the one value with no charset validation upstream. - **An override on the deferred or initial-release path warns** rather than passing unnoticed, since it cannot apply there. - **A raised *major* floor is still capped by `semver-level.sh`**; this input can set `major` explicitly, and the row records the *requested* level so the PR body can show that a level was set by hand even if the cascade later raises it.⚠️ **Not yet usable on an open proposal.** `check-proposal-ongoing` rejects a dispatch while any proposal branch exists — including the branches of the proposal being corrected — so today this works on a fresh proposal, or after cancelling the open one by hand. A follow-up branch makes the guard permit replacing a proposal it can prove is the same release, and retires it once the replacement exists. Worth knowing when judging whether this is complete. Also not covered by tests: `release-version-bumps.bats` exists on a separate branch (#2507) and has no case for the override path yet. # How to test the change? ```bash shellcheck -e SC2086 --severity=warning scripts/*.sh ``` The validation runs before any `cargo release`, so it can be exercised directly against a hand-written candidate file: | `--level-overrides` | result | | --- | --- | | `libdd-alpha` | ERROR: not `CRATE=LEVEL` | | `libdd-alpha=minr` | ERROR: must be major, minor or patch | | `=minor` | ERROR: has no crate name | | `nope=minor` | ERROR + lists the candidates | | `libdd-alpha=minor` on a deferred crate | WARNING, run continues | | `" a=minor , b=major "` | both parsed | | omitted | behaviour unchanged | The PR-body block was rendered through the real jq filter, including a hostile `main_start_ref` of `ref--> <!-- evil`, and round-trips back through `jq` with exactly one `-->` on the line. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: igor.unanua <igor.unanua@datadoghq.com>
gh-worker-dd-mergequeue-cf854d Bot
pushed a commit
that referenced
this pull request
Sep 21, 2026
…evel (#2506) # What does this PR do? `semver-level.sh` combined cargo-semver-checks and cargo-public-api. Both read rustdoc and neither reads a manifest, so two semver-relevant manifest changes came out as `patch`: - a **raised dependency requirement floor** (`http = "1"` → `"1.1"`): every rustdoc signature is byte-identical, yet a consumer pinned to the old version can no longer resolve the crate — conventionally a minor; - an **added cargo feature**: cargo-semver-checks has no lint for an addition at all, and a feature adds no rustdoc item unless it happens to gate one. Two passes are added, both reading the manifest through `cargo metadata`: | pass | reports | | --- | --- | | 2b) dependency requirement floors | `minor` when the lowest version a requirement admits goes up | | 2c) cargo feature surface | `minor` on an added feature; `major` on one removed, or dropped from the set `default` reaches | The second commit is a consequence of the first: `build` moves into the permissive PR-title type list, because scoring a dependency floor as minor would otherwise make `build(deps): bump foo from 1.0 to 1.1` — the conventional title for a dependency change — fail the type rule. The third commit is what lets CI reach any of it. `detect-changes` selected a crate only when a file under its own directory changed, so a PR editing just the root manifest's `[workspace.dependencies]` selected nothing: `has_rust_changes` came out `false`, both the `semver-check` and `validate` jobs were skipped, and every PR title was accepted — a `docs:` title included. Since this workspace declares dependencies version-only at the root and members inherit them with `workspace = true`, that is the ordinary shape of a floor raise here, which left the pass above unreachable from CI. `semver-level.sh` grows a `--list-affected` mode naming every member whose dependency requirements, dependency feature selections or own feature surface moved between two revisions, and `detect-changes` adds those crates to the ones it finds by path. The last three commits answer review findings against the manifest readers. None of them changes what any pass scores on this workspace today: - **Default membership is the closure, not a direct listing.** 2c asked whether `default` *lists* a feature. So a behaviour-preserving refactor — `default = ["foo"]` becoming `default = ["bundle"]` with `bundle = ["foo"]` — read as `foo` losing its default and scored major, while the inverse, emptying a `bundle` that `default` still lists, is a real break that read as no change at all. Rows now carry the closure over the feature graph, which is what a consumer writing `default-features = true` actually gets. - **Dependency rows now carry the feature selection.** They recorded only the requirement, so a root entry that merely gained a feature, or stopped disabling default features, left every inheriting member's facts identical: `--list-affected` named nobody and, with only the root manifest touched, the jobs were skipped again — the same shape of gap the third commit fixes for floors. - **Exclusive bounds are normalized, not tagged.** `req_min` appended an exclusivity bit to the version a bound states rather than advancing past it, so `>` was read as admitting the version it excludes. `>1.2` admits nothing below 1.3.0, so `>=1.2.1` → `>1.2` read as a lowering rather than the raise it is; and `>1.2.3` → the equivalent `>=1.2.4` read as a raise. Bounds now advance to the first version they admit, which drops the flag and returns `version_gt` to a plain triple. # Motivation Reviewing release proposal #2482 surfaced `libdd-capabilities` proposed as `patch`, when #2350 had moved its `http` requirement from `^1` to the workspace entry at `^1.1`. That is a minor, and nothing in the pipeline could see it: the version had moved *into* `[workspace.dependencies]`, so even a textual diff of the crate's own `Cargo.toml` shows only `{ workspace = true }` with no version in it. # Additional Notes Points reviewers may want to weigh: - **Read through `cargo metadata`, not `Cargo.toml`.** That is what resolves `{ workspace = true }` to the version the root manifest declares, and what surfaces the implicit feature an `optional = true` dependency creates. - **Dependencies are keyed by `.rename` as well as name/kind/target.** A crate aliasing two versions of one package emits an identical name, kind and target for both; keyed without the alias, the second matches the first's baseline requirement and an unchanged pair reads as a raise. - **An exclusive bound is advanced to the first version it admits**, `>` excluding everything up to and including the components it states: `>1.2.3` starts at 1.2.4, `>1.2` at 1.3.0 and `>1` at 2.0.0. So `>=1.2.3` → `>1.2.3` reads as the narrowing it is, `>=1.2.1` → `>1.2` as the raise it is, and `>1.2.3` → the equivalent `>=1.2.4` as no change at all. A pre-release bound is the exception and stays where it is: `>1.2.3-rc.1` admits 1.2.3 itself, so the release version this reader already compares is that bound's exact floor, and advancing it would overstate the requirement. `req_min` was checked against `semver` 1.0.28's own `VersionReq::matches` over 33 requirement forms — every operator at one, two and three components, the four shapes this workspace uses, and both pre-release cases — and agrees on all of them. - **A raised *major* floor is capped at `minor` on purpose.** Whether that forces the dependent to major is `release-version-major-bumps.sh`'s decision, made with the dependency graph this script cannot see; `max_level()` lets it win from there. - **The two passes stop at different points.** 2b can only report minor, so minor ends it. 2c can report major, so it runs on until major — which matters for a crate with no library target, where cargo-semver-checks is skipped entirely and nothing else watches the feature table. - **Feature removals are a backstop, not the primary check.** For a library crate `feature_missing` and `feature_not_enabled_by_default` get there first; both were verified to *fail* the run rather than merely warn, using a two-crate repro against the pinned invocation. The closure above is what keeps the backstop from contradicting them: cargo-semver-checks resolves the default set transitively, so keyed on direct membership this pass would have reported major over a refactor the lint passes. - **Dependency feature facts are selected on, not scored.** Enabling a feature in a dependency can change this crate's own API — an item reached through a glob re-export appears — but the manifest cannot say whether it did, and the passes that read rustdoc can. So the columns widen what `--list-affected` names and assign no level of their own; 2b's key stops before them, so a feature move never reads as a requirement change. - **Deliberately not scored:** dev-dependencies, a widened requirement, a dependency added or removed outright, and a change to what a feature *enables* for its own sake (the two `*_enables_feature` lints' job) — that last reaches 2c only where it moves the set `default` reaches. On the detection commit: - **`--list-affected` lives in `semver-level.sh` rather than a script of its own**, because it reuses `manifest_facts_at_rev` — now able to read the whole workspace in one extraction — so what the detector considers a manifest fact cannot drift from what the passes score. A detector considering *fewer* facts silently selects nothing and reports "no change", which is the failure this commit fixes; there are no shell tests to catch that drift. 19 lines are new, the 51 they lean on are shared. - **The mode compares from `git merge-base`**, matching the `base...HEAD` the changed-file search uses. Measured from the baseline tip instead, a branch behind the baseline reports every crate that moved *on* the baseline since the fork, putting another branch's changes on this one's report — and since scoring uses the tip, a feature added on the baseline would read as a removal, i.e. a spurious major. - **Publishability stays the caller's business.** The mode lists workspace members; `detect-changes` keeps its own `publish` filter, so a `publish = false` member such as `libdd-agent-client` shows up in the list and is dropped where that filter already lives. - **Cost.** A crate selected only by moved facts still gets the full treatment, cargo-semver-checks and cargo-public-api both building rustdoc, so a one-line root bump now costs ~12 of those instead of zero, and a root entry that only gains a feature costs one per inheritor too — 20 for `serde_json`. That is deliberate: a changed floor or a newly enabled dependency feature can alter a crate's API through re-exports. If it bites, the cheap follow-up is a mode running only passes 2b/2c for those crates. Release-proposal PRs are unaffected — they carry `skip-pr-title-semver-check`, and each member's `version` is literal, so the path search already finds them. - **The release path reports the same change rather than releasing for it.** `commits-since-release.sh` selects a crate's commits with `git log "$COMMIT_RANGE" -- "$CRATE_PATH"`, so a root-only floor raise leaves every inheriting crate with no commits and `release-version-bumps.sh` defers it. That is the right outcome, not a second instance of the bug above: the crate's code is unchanged, the requirement its published version states is still true of that code, and requirements are minimums, so a consumer combining it with a freshly published sibling that asks for the raised floor resolves the newer dependency anyway. Deferring moves neither the version nor the tag, so the raise stays in range and the crate's next release is still scored a minor for it — late, not wrong — while the case where a crate's code does need the raised version always arrives with a change to a file of its own, which the path search already finds. What is missing there is only the saying so: a deferred crate is recorded as level `none` and reads as "nothing happened". A follow-up reports those moves at the deferral point instead of releasing 12 crates that needed nothing. Selection, each case a root-manifest edit and nothing else: | root edit | before | after | | --- | --- | --- | | `bytes` floor `1.11` → `1.12` (12 members inherit it) | 0, both jobs skipped | exactly the 12 inheritors | | + a feature added to one crate | that crate, by path | same, plus the 12 | | `serde_json` gains a feature (20 members inherit it outside dev-dependencies) | 0, both jobs skipped | exactly those 20 | | `serde_json` stops disabling default features | 0, both jobs skipped | exactly those 20 | | baseline unchanged | — | none | Scoring, over the same revisions, is unmoved by any of the three follow-ups: 2b's projection is byte-identical across all 698 dependency rows of the workspace, the 217 feature rows are byte-identical too, and all 149 distinct requirement strings in the workspace keep the floors they had — every bound here being inclusive with a full triple, the normalization has nothing to advance. So the floor and feature passes see exactly what they saw before. Both manifest passes also produce byte-identical output after the field shift in the shared reader (`bytes (normal): ^1.11 -> ^1.12`; `Cargo feature added / added: new-thing`). Scoring one of the 20 selected crates end to end reports `patch` — "No public API changes detected" — rather than a level invented from the new columns. The closure was checked against cargo-semver-checks 0.47.0 and 0.48.0, the pinned version, on a two-crate repro: `feature_not_enabled_by_default` passes the behaviour-preserving refactor and fails the inverse, exactly as the closure does, and on `libdd-common`'s real feature graph the pass and the lint name the same eight features. The refactor now scores `minor` for the genuinely new feature name rather than `major`. Everything above runs under `RUSTUP_TOOLCHAIN=1.92.0` as the workflow does. `shellcheck` on the script and on the extracted `run:` block (actionlint's `-e SC2086` profile) reports nothing that was not already there. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: igor.unanua <igor.unanua@datadoghq.com>
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
1 participant
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.
Release proposal for libdd-capabilities-impl, libdd-crashtracker, libdd-data-pipeline, libdd-ddsketch, libdd-ffe, libdd-http-client, libdd-ipc, libdd-library-config, libdd-live-debugger, libdd-otel-thread-ctx, libdd-remote-config, libdd-shared-runtime, libdd-telemetry, libdd-trace-utils, libdd-tracer-flare and their dependencies
This PR contains version bumps based on public API changes and commits since last release.
These publishable workspace crates are not part of this release but their dependency requirement was rewritten on this branch while their published version still requires the old major. If they are a dependency on your deployment not including them in the release could result in duplicate packages or symbol incompatibility.
libdd-common5.2.0→6.0.0affects:libdd-profiling,libdd-samplinglibdd-trace-utils11.0.0→12.0.0affects:libdd-samplinglibdd-capabilities
Next version:
3.0.1Semver bump:
patchTag:
libdd-capabilities-v3.0.1Commits
libdd-common
Next version:
6.0.0Semver bump:
majorTag:
libdd-common-v6.0.0Commits
libdd-ipc-macros
Next version:
1.0.1Semver bump:
patchTag:
libdd-ipc-macros-v1.0.1Commits
libdd-otel-thread-ctx
Next version:
1.1.0Semver bump:
minorTag:
libdd-otel-thread-ctx-v1.1.0Commits
libdd-tinybytes
Next version:
1.1.3Semver bump:
patchTag:
libdd-tinybytes-v1.1.3Commits
libdd-capabilities-impl
Next version:
5.0.0Semver bump:
majorTag:
libdd-capabilities-impl-v5.0.0libdd-common: ^5.1.1 → ^6.0.0Commits
libdd-http-client
Next version:
2.0.0Semver bump:
majorTag:
libdd-http-client-v2.0.0libdd-common: ^5.1.1 → ^6.0.0Commits
libdd-remote-config
Next version:
5.0.0Semver bump:
majorTag:
libdd-remote-config-v5.0.0libdd-common: ^5.2.0 → ^6.0.0Commits
libdd-shared-runtime
Next version:
4.0.0Semver bump:
majorTag:
libdd-shared-runtime-v4.0.0libdd-common: ^5.2.0 → ^6.0.0Commits
libdd-trace-utils
Next version:
12.0.0Semver bump:
majorTag:
libdd-trace-utils-v12.0.0libdd-common: ^5.2.0 → ^6.0.0Commits
libdd-ffe
Next version:
2.0.0Semver bump:
majorTag:
libdd-ffe-v2.0.0libdd-common: ^5.1.1 → ^6.0.0libdd-remote-config: ^3.0.0 → ^4.1.0libdd-trace-protobuf: ^4.0.1 → ^5.0.0Commits
libdd-dogstatsd-client
Next version:
6.0.0Semver bump:
majorTag:
libdd-dogstatsd-client-v6.0.0libdd-common: ^5.2.0 → ^6.0.0Commits
libdd-telemetry
Next version:
8.0.0Semver bump:
majorTag:
libdd-telemetry-v8.0.0libdd-common: ^5.2.0 → ^6.0.0Commits
libdd-trace-obfuscation
Next version:
8.0.0Semver bump:
majorTag:
libdd-trace-obfuscation-v8.0.0libdd-common: ^5.2.0 → ^6.0.0libdd-trace-utils: ^11.0.0 → ^12.0.0Commits
libdd-tracer-flare
Next version:
3.0.0Semver bump:
majorTag:
libdd-tracer-flare-v3.0.0libdd-common: ^5.2.0 → ^6.0.0libdd-trace-utils: ^11.0.0 → ^12.0.0Commits
libdd-crashtracker
Next version:
3.0.0Semver bump:
majorTag:
libdd-crashtracker-v3.0.0libdd-common: ^5.2.0 → ^6.0.0Commits
libdd-data-pipeline-core
Next version:
1.0.0Semver bump:
majorTag:
libdd-data-pipeline-core-v1.0.0Warning: this is an initial release. Please verify that the version and commits included are correct.
libdd-trace-stats
Next version:
9.0.0Semver bump:
majorTag:
libdd-trace-stats-v9.0.0libdd-common: ^5.2.0 → ^6.0.0libdd-trace-obfuscation: ^7.0.0 → ^8.0.0libdd-trace-utils: ^11.0.0 → ^12.0.0Commits
libdd-data-pipeline
Next version:
10.0.0Semver bump:
majorTag:
libdd-data-pipeline-v10.0.0libdd-common: ^5.2.0 → ^6.0.0libdd-trace-obfuscation: ^7.0.0 → ^8.0.0libdd-trace-stats: ^8.0.0 → ^9.0.0libdd-trace-utils: ^11.0.0 → ^12.0.0Commits
libdd-ipc
Next version:
2.0.0Semver bump:
majorTag:
libdd-ipc-v2.0.0libdd-common: ^5.2.0 → ^6.0.0libdd-trace-stats: ^8.0.0 → ^9.0.0Commits
libdd-live-debugger
Next version:
1.0.0Semver bump:
majorTag:
libdd-live-debugger-v1.0.0Warning: this is an initial release. Please verify that the version and commits included are correct.