Switch to independent (per-package) versioning

[leoromanovsky]

Motivation

The monorepo currently uses Lerna fixed versioning — all 3 packages share one version and are always released together. This causes empty version bumps for node-server (consumed by dd-trace-js) when only browser changes ship, creating noise for downstream consumers.

This PR switches to independent versioning so each package has its own version and release lifecycle.

Changes

Lerna is now configured in "independent" mode, with each package's package.json as its own version source of truth. All scripts that previously read a single version from lerna.json have been updated to read from the relevant package.json instead — the build system resolves the version by walking up from the package being built, the peer-dependency updater maps each internal dep to its actual version, and the CI validation script now checks that internal dependency versions are consistent across packages rather than enforcing a single global version.

The release workflow uses per-package git tags (core-v{version}, browser-v{version}, node-server-v{version}). When a GitHub Release is created with one of these tags, the workflow parses the tag to determine which package to publish and validates the version against that package's package.json. If the package depends on @datadog/flagging-core and that version isn't on npm yet, core is published first automatically. Changelog generation now produces per-package headers (e.g. ## @datadog/openfeature-browser v1.2.0) and filters commits to the affected package.

From a developer perspective, yarn release now prompts for a version bump per changed package instead of applying one version to everything. Release branches and GitHub Releases are scoped to individual packages (e.g. release/browser-v1.2.0), and you create a separate GitHub Release for each package tag that needs publishing. Everything else — yarn build, yarn test, yarn format:check — works exactly the same.

Decisions

• Tag naming: core-v{version}, browser-v{version}, node-server-v{version} — clear prefix-based convention
• Release workflow: Only the tagged package is published. Core is auto-published first if needed by a dependent package and not yet on npm.
• Single CHANGELOG.md: Kept, but each release section is scoped to the package name
• Backwards-compatible changelog parsing: getLastReleaseTagName() matches both old ## v1.2.3 and new ## @datadog/package-name v1.2.3 formats

Test plan

• yarn build succeeds (all 3 packages)
• yarn test passes (368 tests: 25 core + 106 browser + 237 node-server)
• yarn format:check passes
• yarn lint passes
• bash scripts/versions-validate.sh passes with packages at same version
• Manually verify release workflow tag parsing with a dry-run release

[greghuels]

@leoromanovsky This is going to complicate our release notes and changelog. It's a lot easier to grok if everything operates under the same version. IMO, a noop isn't that big of a deal.

[leoromanovsky]

@leoromanovsky This is going to complicate our release notes and changelog. It's a lot easier to grok if everything operates under the same version. IMO, a noop isn't that big of a deal.

Just exploring it's not ready for review yet; personally don't think it's too big of a deal for nodejs and browser to be released even if one doesn't have any changes for now.