Feature/prerelease #413
Merged
Feature/prerelease #413
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Closed
20688be to
884e9a3
Compare
|
@jacksbox Are you still working on this? |
|
@williamluke4 nope, I'm waiting for a review of the PR :) |
williamluke4
approved these changes
Mar 3, 2022
|
removed my leftover todo comments |
danth
approved these changes
Mar 7, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First take on making prereleases possible
I had some time implementing my feature request from here #386
What is does
It is a first take on enabling to do prereleases with python-semantic-release. For a start I implemented a config option to define what suffix a prerelease should use (e.g.
alpha,beta,rc- defaulting tobeta) as well as a cli flag to trigger a prerelease.Using the
--prereleaseflag will trigger the determined next version for the cli commandsprint_version,versionandpublishto be a prerelease.The version number will be determined as normal:
Find the last (important) non-prerelease version and determine the bump (or use the forced level)
Bump the version and append
-{prerelease_tag}.0to it.Should there already be a prerelease version for the determined new version (
1.0.0-beta.0already exists for the next version beeing1.0.0) then the prerelease number will be incremented, leading to1.0.0-beta.1in the previouse example.I tried to make my code additions as unintrusive as possible and added/updated tests to check the behavior. All unit tests pass, so I'm optimistic that it will work in all cases.
Happy to get feedback and a review :)
One finding: It would be nice to have some full end-to-end tests, without mocks (maybe expect for the git interaction) to see if all parts work well together. Wdyt?