mirror of
https://github.com/conventional-commits/conventionalcommits.org.git
synced 2026-03-12 02:17:21 -05:00
what is the recommended way to handle deprecations? #195
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/conventionalcommits.org#195
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @bshaffer on GitHub (Dec 20, 2023).
I assume since it's neither a feat or a fix, the recommended way to handle deprecations would be
chore(deprecation):or simplychore: deprecate such and such. But would adeprecated:tag ordeprecation:tag also make sense? Curious if anyone has any thoughts on this.@javier-godoy commented on GitHub (Jan 2, 2024):
My colleagues use
deprecate:We don't like usingfeat:because we reserve it for introducing new features, and we don't likechore:either, because it doesn't convey a Semantic Versioning level. However, many guidelines based on conventional commits don't specify a type for deprecations.@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 usechore!: 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.