Open LefterisJP opened 4 years ago
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 …
Hey @rixx we already did that and use it in our project. The pypi fork is here: https://pypi.org/project/rotki-releases/
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: https://github.com/pretalx/pretalx/commit/563dd551a05ee3b325bac80c5008fb6b2325d69d
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 than0.0
, I vendoredreleases
, 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.
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:
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.