Prerelease option

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 to rc
• 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 + fix will result in 1.1.0-rc.0
  • last version was a prerelease and no commits which would bump the version were made -> prerelease bump 1.0.0 + feat + fix => 1.1.0-rc.0 + feat + fix results in 1.1.0-rc.1
  • last version was a prerelease and 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 in 2.0.0-rc.0

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 😃

[jacksbox]

…and here is the PR: https://github.com/relekang/python-semantic-release/pull/413

[jacksbox]

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:

• it only runs on a certain branch, but prereleases will probably be done from feature branches instead of the release one
• tags are just analysed in order, it is not checked if the tag is actually on the current branch. For prereleases we only want tags on the current branch…
• please, not be offended by this last point, it is meant as helpful critic: the codebase feels a bit messy and unstructured - i spend quite some time exploring what is going on and where and found it hard to follow - if we compare it to the semantic-release src 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…