Repository navigation
Prerelease option #386
Description
Description
I would like to propose (and integrate) a prerelease option, to create releases with version numbers like 1.0.0-alpha.0, 1.0.0-rc.0, etc.
Use cases
Publishing alpha/beta/rc versions can be really helpful when working with multiple repositories or to preview (and test) new features.
Possible implementation
I would propose following implementation:
- new cli option
--prerelease=<str>, if the prerelease option is there but has no value it defaults torc - the new version number is determined as follows (if called with
prerelease):- last version was a normal one -> normal version bump and prerelease bump:
1.0.0+feat+fixwill result in1.1.0-rc.0 - last version was a
prereleaseand no commits which would bump the version were made -> prerelease bump
1.0.0+feat+fix=>1.1.0-rc.0+feat+fixresults in1.1.0-rc.1 - last version was a
prereleaseand commits which require a bump were made -> normal version bump and prerelease bump
1.0.0+feat+fix=>1.1.0-rc.0+BREAKING CHANGES+ results in2.0.0-rc.0
- last version was a normal one -> normal version bump and prerelease bump:
As this determination needs information about the last version as well as the last none prerelease version, we would need to integrate a new get_new_prerelese_version function to be called on prereleases.
The current get_new_version needs to be adjusted to ignore prerelease versions to prevent wrong determinations.
Personally I would find this feature really useful and I was glad to have it in the js world before. I would also offer to write the integration :)
Activity
github-actions commentedon Oct 17, 2021
This feature request has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.
jacksbox commentedon Oct 19, 2021
I started working - or let's call it more exploring the codebase as preparation - on this task and came to the conclusion that this is not easily done without a lot of rewriting of the existing code as there are quite some obstacles:
semantic-releasesrc code (which seems to be the inspiration for this package) it is much more easy to follow and thus to extend...Edit: there is a Issue about making this project plugin based which could be a good step to alleviate this
Edit 2: my. main painpoint why I wrote this is probably the parsing of current and previous version - current versions are parsed from tag or file, while previous versions are parsed from commit msg - all parsings are done slightly different (regex, str compare, ...) which seems a bit error prone (especially the commit parsing). Maybe this could be unified, e.g. by only using tags, or only using commit messages... I guess I'll create an issue about this with some proposals.
All in all, I won't continue working on this tasks, as I would need to change so much basic functionality and without some bigger refactoring the only way to implement this would be a hacky solution...
PS: I'm all up for some bigger refactoring, but I think that should be discussed by more maintainers...
github-actions commentedon Nov 11, 2021
This feature request has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.
jacksbox commentedon Feb 10, 2022
Working on this again and currently preparing a PR :)
jacksbox commentedon Feb 10, 2022
...and here is the PR: #413
github-actions commentedon Mar 5, 2022
This feature request has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.