We work by the git-flow workflow and we stick to semantic versioning. Today we discussed how to handle deprecations. Two questions have arisen:
"Gracefully" means: The feature is still supported but a warning is shown in development environment. Support will be removed with a major release (in case of v1.12.0 with v2.0.0 or a subsequent major release).
Given we want to drop support for a feature in v3.0.0 while the last 2.x-release is v2.14.0. So 2.14.0 must support the feature while 3.0.0 must drop support for the feature, as any feature supported in 3.0.0 cannot be dropped before 4.0.0.
Subsequently we must remove the feature in the release/3.0.0 branch. But according to git-flow, a release-branch should only accept bug fixes.
Any advice highly appreciated!
tl;dr: One way to achieve this is to simply remove the feature on develop after the last 2.X release branch is made. Or feature flag the removal, and disable it on the first 3.X release branch. If you can't do either of those for some reason, it's still OK to do it on release.
Details:
Usually you can treat dropping this feature the same way you would treat adding a new big feature by simply merging it into develop. The only difference is that you need to make sure you get the timing right such that you don't complete the code removing the feature into develop until the last 2.X release branch is created. The next release branch that comes off of develop will have the code and will be the 3.X release. If the issue is that you don't know for certain when the last 2.X release will be, you could either wait until you do know and then merge the removal code into develop, or, consider feature flagging the removal with a config change. Then your change on the release branch whenever you create the 3.X version would simply be toggling the config.
That being said, perhaps ultimately it doesn't matter anyway:
But according to git-flow, a release-branch should only accept bug fixes.
Note there is no such thing as a Git Flow Authority which dictates what you must do. There is a popular standard Git Flow, but here I use the word "standard" to just mean "original" version that many companies use as a guideline. It is not "the" standard, as no such standard exists. I think the particular text you're referring to regarding release branches (emphasis mine):
This new branch may exist there for a while, until the release may be rolled out definitely. During that time, bug fixes may be applied in this branch (rather than on the
developbranch). Adding large new features here is strictly prohibited. They must be merged intodevelop, and therefore, wait for the next big release.
Note even "strictly prohibited" is a (strongly) suggested best practice. There are no Git Flow Gods that will strike you down if you ever violate this rule. Besides, in your case, it could be easily argued that removing a deprecated feature on the release branch is not considered "adding a large new feature". (Even if we ignore the distinction between add/remove and new/old, perhaps the feature being removed is not "large".) Regardless, sometimes new large features do get added to a release branch, for a variety of reasons. This may violate best practices, but in the real world it's not always possible to follow best practice 100% of the time. Think of Git Flow as a guideline to work in, when it makes sense to do so. Note that Vincent Driessen specifically points out in the Note of Reflection that he didn't intend for Git Flow to become "dogma or panacea".