Feature Request: Special Unstable-Prehistory-Mode that's not disabled after 1.0.0

[LefterisJP]

Reasoning behind the request

Hello!

So I have a feature request which may sound strange to you as it does not 100% follow the semantic versioning ethos. But there are projects like mine which like things simple. I want all issues under a release to be put as part of that release when rendered.

So essentially what unstable-prehistory-mode does, except I want it to also carry on after v1.0. I know I can start specifying which issue belongs to each release, but at that point I am fighting the tool instead of using it.

Why you may ask? For our project:

• Each minor release after v1.0 is feature heavy (and perhaps some bugs).
• Each patch release is mostly quick hotfixes for stuff that break a previous minor release.
• And we are a bit reluctant to use the major version number. So no v2.0 soon.

With the above characteristics the default way the tool operates does not really work.

Feature request specification

Add a new switch that essentially does not stop the unstable-prehistory-mode after v1.0.

[rixx]

I see you implemented this yourself, @LefterisJP – do you plan to push your changes to PyPI as a fork/derivative package? I could absolutely need exactly what you implemented, and installing from PyPI is less of a hassle than from a random GitHub fork URL …

[LefterisJP]

Hey @rixx we already did that and use it in our project. The pypi fork is here: https://pypi.org/project/rotki-releases/

[rixx]

Just an update: I used your fork for the past three years (thank you for that!). Now that my project has switched to CalVer, and the existing code failed hard on my versioning starting at YYYY.1.0 rather than 0.0, I vendored releases, threw out 80% of it, and the remains handle a completely linear history pretty well. So if anybody else stumbles across this issue in search of a fully linear mode, this might help: pretalx/pretalx@563dd55

[LefterisJP]

Just an update: I used your fork for the past three years (thank you for that!). Now that my project has switched to CalVer, and the existing code failed hard on my versioning starting at YYYY.1.0 rather than 0.0, I vendored releases, threw out 80% of it, and the remains handle a completely linear history pretty well. So if anybody else stumbles across this issue in search of a fully linear mode, this might help: pretalx/pretalx@563dd55

Thank you rixx! Makes me really happy to hear you guys at pretalx were using our small fork. I have used pretalx many times during conference applications, most recently at Protocolberg in Berlin!

I will keep your link in mind if we ever switch to Calver! It's really nice of you to share with us.