[GH-ISSUE #557] what is the recommended way to handle deprecations? #5954

New Issue

GiteaMirror · 2026-05-12T17:56:38-05:00

GiteaMirror commented

2026-05-12 17:56:38 -05:00

Originally created by @bshaffer on GitHub (Dec 20, 2023).
Original GitHub issue: https://github.com/conventional-commits/conventionalcommits.org/issues/557

I assume since it's neither a feat or a fix, the recommended way to handle deprecations would be chore(deprecation): or simply chore: deprecate such and such. But would a deprecated: tag or deprecation: tag also make sense? Curious if anyone has any thoughts on this.

Originally created by @bshaffer on GitHub (Dec 20, 2023). Original GitHub issue: https://github.com/conventional-commits/conventionalcommits.org/issues/557 I assume since it's neither a feat or a fix, the recommended way to handle deprecations would be `chore(deprecation):` or simply `chore: deprecate such and such`. But would a `deprecated:` tag or `deprecation:` tag also make sense? Curious if anyone has any thoughts on this.

GiteaMirror commented

2026-05-12 17:56:39 -05:00

@javier-godoy commented on GitHub (Jan 2, 2024):

My colleagues use deprecate: We don't like using feat: because we reserve it for introducing new features, and we don't like chore: either, because it doesn't convey a Semantic Versioning level. However, many guidelines based on conventional commits don't specify a type for deprecations.

@javier-godoy commented on GitHub (Jan 2, 2024): My colleagues use `deprecate:` We don't like using `feat:` because we reserve it for _introducing new_ features, and we don't like `chore:` either, because it doesn't convey a Semantic Versioning level. However, many guidelines based on conventional commits don't specify a type for deprecations.

GiteaMirror commented

2026-05-12 17:56:40 -05:00

@ph-One commented on GitHub (Jan 18, 2024):

Thoughts on feat(deprecate): Deprecate {{ thing }}? This would generate a feature release (as I would expect from a deprecation). One other option would be to use chore!: Deprecate {{ thing }}, but this equates to a MAJOR version change, which doesn't exactly feel right in all cases, especially since deprecation isn't truly a breaking change, just the first step in a breaking change. 🤷‍♂️

I'm here for the suggestions, as this feels like a common action that isn't called out in the spec.

@ph-One commented on GitHub (Jan 18, 2024): Thoughts on `feat(deprecate): Deprecate {{ thing }}`? This would generate a feature release (as I would expect from a deprecation). One other option would be to use `chore!: Deprecate {{ thing }}`, but this equates to a MAJOR version change, which doesn't exactly feel right in all cases, especially since deprecation isn't truly a breaking change, just the first step in a breaking change. :man_shrugging: I'm here for the suggestions, as this feels like a common action that isn't called out in the spec.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#5954