feat(releasing): add deprecation.d fragment system#25442
feat(releasing): add deprecation.d fragment system#25442thomasqueirozb wants to merge 34 commits into
Conversation
…ow commands and release integration
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
…h script" This reverts commit 6d0e0c0.
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
…rsion not announcement_version
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
… keyword, rewrite next on release
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
…r new fragment fields
…s and datadog_metrics series v1
… and next-release detection
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the Rust Doc will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the VRL Playground will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the Rust Doc will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the VRL Playground will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
…log array not the first ]
…authenticated GitHub API
…ad of unauthenticated GitHub API" This reverts commit 3b2a6f0.
d2b0864 to
0bc71cc
Compare
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the Rust Doc will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the VRL Playground will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0bc71ccdd4
ℹ️ 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".
| @@ -0,0 +1,7 @@ | |||
| --- | |||
| what: "FAKE EXAMPLE — `fake_option` on the `fake_sink` sink [remove before merging]" | |||
There was a problem hiding this comment.
Remove the fake deprecation fragment before merge
This file is parsed as a real deprecation entry (the loader includes all .md files except README.md), so it is emitted into release metadata and user-facing notes; the generated 0.56.0.cue in this same commit already includes this fake item under deprecation_announcements. Leaving it in deprecation.d will pollute future release outputs with test-only content.
Useful? React with 👍 / 👎.
| the deprecated configuration or feature being used (when possible). | ||
| - Add the deprecation to [docs/DEPRECATIONS.md](../docs/DEPRECATIONS.md) to track migration (if applicable) and removal | ||
| - Add a deprecation notice file to [`deprecation.d/`](../deprecation.d/) following the format described in | ||
| [`deprecation.d/README.md`](../deprecation.d/README.md). Both `announcement_version` and `deprecation_version` |
There was a problem hiding this comment.
Do we need announcement_version? We can incorporate to the release process like we do for the changelog.d fragments.
Also, let's remove the TBD and next from the accepted values for deprecation_version. We should always set a version number.
One more concern, setting the deprecation_version is a new commitment now, we could keep it like this for now but I wouldn't want to delay a release for this. I think the simplest way to workaround this is to bump deprecation_version before a release.
There was a problem hiding this comment.
Do we need announcement_version? We can incorporate to the release process like we do for the changelog.d fragments.
Useful since I added a planned_deprecations section to the release, which gets rendered at the bottom. It is fully incorporated into the release process.
Also, let's remove the
TBDandnextfrom the accepted values fordeprecation_version. We should always set a version number.
OK with removing TBD, but keeping next is a good idea so that PRs don't need to hard code deprecation versions. Hypothetical scenario: PR opened after 0.55 release set the deprecation_version to 0.56 but the PR only got merged after the 0.56 release. The deprecation version would then be in the past
One more concern, setting the
deprecation_versionis a new commitment now, we could keep it like this for now but I wouldn't want to delay a release for this. I think the simplest way to workaround this is to bumpdeprecation_versionbefore a release.
Agreed. I added the deprecation vdev command helper to help us keep track of this a little better. Worst case scenario we just bump the version before the release.
There was a problem hiding this comment.
Useful since I added a planned_deprecations section to the release, which gets rendered at the bottom. It is fully incorporated into the release process.
My goal is to simplify this process as much as possible. I believe we can drop this version completely and bundle this in the deprecation policy. We can state that once the deprecation fragment is merged, it will be announced with the next release.
The deprecation version would then be in the past
I believe that's fine since we don't promise to actually delete the deprecated functionality. The intention is to communicate that we will not remove functionality before a version X.
| for line in e.description.lines() { | ||
| writeln!(s, "\t\t\t\t{line}").unwrap(); | ||
| } | ||
| s.push_str("\t\t\t\t\"\"\"#\n"); |
There was a problem hiding this comment.
Nit: Is there any cue related crate to help with this?
|
|
||
| whats_next: [] | ||
|
|
||
| deprecations: [ |
There was a problem hiding this comment.
Reminder to delete release artifacts.
Summary
Introduces a structured
deprecation.d/directory to track deprecation notices as versioned markdown fragments, replacing the hand-maintaineddocs/DEPRECATIONS.mdtable.Each fragment has YAML frontmatter with
what,deprecation_version(semver orTBD; acceptsmajor.minorshorthand), and a requiredannouncement_version. Both fields acceptnextas a value (the very next release) — the release tooling rewritesnextto the concrete version automatically. The body is free-form Markdown for migration guidance.Two new
vdevcommands:cargo vdev check deprecations— validates all fragments (wired into CI via.github/workflows/deprecation.yaml)cargo vdev deprecation show [--version X.Y.Z]— displays notices grouped by enacted in next release, announced in next release, and pre-existingThe release CUE generator now reads
deprecation.d/and renders three new sections:deprecations(enacted),deprecation_announcements(newly announced), andplanned_deprecations(pre-existing). Enacted and announced fragment files are rewritten/retired automatically, mirroring changelog fragment handling.All 6 existing entries from
docs/DEPRECATIONS.mdhave been migrated to fragments.docs/DEPRECATION.mdand the minor release issue template are updated accordingly.Notes for reviewers
The following commits are intentionally reverted from this PR and should be restored after review:
feat(releasing): expose generate-cue as standalone release subcommandfeat(releasing): in dry-run mode, create branches from current branch instead of masterVector configuration
NA
How did you test this PR?
cargo test -p vdev— 66 tests passcargo vdev check deprecations— validates all 6 migrated fragmentscargo vdev deprecation show— verified grouped output with colorcargo vdev release prepare --version 0.56.0 --vrl-version 0.32.0 --dry-runhttp://localhost:1313/releases/0.56.0/example-fake-deprecation.mdupdatesnextto0.56.0Change Type
Is this a breaking change?
Does this PR include user facing changes?
no-changeloglabel to this PR.References
NA