Separate deprecations and removals sections by default

[abravalheri]

Hello, thank you very much for the project.

I am opening this issue to gauge the interest of the maintainers in separating the sections regarding deprecations and removals by default.

The reasoning behind the request is the following:

Many projects use some form of https://semver.org/: (or at least "attempt" SemVer), which prescribes the following:

• deprecations are introduced in minor version bumps
• removals are done in major version bumps.

Some projects then use the fragments to detect which kind of version bump to apply (see https://github.com/jaraco/jaraco.develop/blob/v8.17.6/jaraco/develop/towncrier.py#L36-L43)

So in this context, it is useful to have these 2 kinds of releases clearly separated not only for communication but also for automatic detection.

Now, a user could write its own custom configuration, however, as discussed in jaraco/skeleton#169 this leads to an "explosion" in terms of copy+pasted boilerplate, which is undesirable.

Therefore my question is:

Is the towncrier team receptive to a potential change to separate the deprecation and removal sections/fragments by default?

If not, is there a way we could write a plugin/extension that achieves that without requiring every project to copy+paste configuration?

The issue #77 is related, however I understand that the resolution for that ticket was an advice for using custom configuration.

[adiroiban]

Thanks for the report.

There isn't much of a towncrier team... just loosly related contributors

Issue #77 is from 2017 I think that we should reconsider it

The deprecation + removal was carried over from twisted/twisted

---

I understand the need for separate categories, but they are kind of similar.
It's best to start acting on deprecating API now, rather than waiting for the removal.

Some projects might use calver.

Also, some projects might deprecate an API, with the info that it will be removed in the future,
but it doesn't mean that it will be removed in the next major release.

---

I think that may projects don't even bother with categories ... only have a list of changes and they "tag" backward incompatible changes

I see that the GitHub Release only has What's Changed and New Contributors

I think that it would help to see what other projects are using and what are the defaults for towncrier alternatives

---

I prefer to have fewer categories.

Maybe we can have this converted into a Discussion and enable the poll

[abravalheri]

Thank you very much @adiroiban.

Just to provide a bit more context, I believe that all projects listed in
https://github.com/search?q=%2F-m+jaraco.develop.finalize%2F&type=code + setuptools would benefit from such approach, based on the feedback in jaraco/skeleton#169 (comment).

In other words: all projects that use the skeleton "framework"/template would benefit from this separation.

There is also other projects that add deprecation fragment types:

• https://github.com/search?q=%2Ftool.towncrier.fragment.deprecation%2F+path%3A*.toml&type=code
• https://github.com/search?q=%2Fdirectory+%3D+%22deprecation.*%22%2F+path%3A*.toml&type=code

(Please ignore the forks, I haven't found a way of cleaning up the Github search from repeated results).

---

Maybe we can have this converted into a Discussion and enable the poll

Yes we can do that, if this project discussion track has engagement this may be a good way of gauging interest.

[abravalheri]

I have created a discussion with poll in #705 as suggested.