search

octue / conventional-commits

Continuous deployment via Conventional Commits
MIT License
4 stars 0 forks source link

Add commit codes for deprecation and subsequent removal #56

Closed cortadocodes closed 2 years ago

cortadocodes commented 2 years ago

@thclark what do you think about having e.g. DPR for deprecation and REM for removal of previously deprecated code?

Additionally, should breaking change alerts be attached to releases that:

  1. Deprecate code (the code should still work with the same interfaces etc. but the old use will be discouraged)
  2. Remove previously deprecated code (the code will no longer work with the old interfaces at all)
thclark commented 2 years ago

The breaking change should be applied at the point of code removal not code deprecation, because that's when the code actually breaks.

Not sure about DPR and REM... I quite like the idea that we can pull out an !!!!UPCOMING CHANGES!!!! section if we adopt DPR. But I think I think I'd normally use REF or CHO (aka "I'm tidying stuff up") for removal of deprecated code... and you could plausibly deprecate one thing as part of an ENH or FEA.

We could treat it a bit like a BREAKING CHANGE in that if you have DEPRECATION in the commit body it knows what it is? Then we can have a deprecation applied orthogonally to the actual purpose of the commit. In essence we're adding multiple attributes to a commit and we want to be careful not to obfucscate that.

cortadocodes commented 2 years ago

Ok I'll update the way I version control deprecations and removals.

I agree about the DEPRECATION note in the commit body - this gives us greater flexibility as you say. I'll add it as a new feature request.

cortadocodes commented 2 years ago

Superseded by #57