-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle pre-release channels #90
Comments
so what you want is to enchance the branches:
- master
name: beta
prerelease: true
- alpha-branch
name: alpha
prerelease: true which then adds to the version When the pre-release is set to false it would then ignore this and just set the version to Another option would just to add the property or would it be better to provide What do you think is the most convenient way? |
Both would be nice and do the job, but the most permissive (and maybe the simplest) would be to provide the prerelease param to the cli: |
When prerelease is given as a parameter with the value 'beta', the version would look like: x.y.z-beta.1 Fixes: convco#90 Signed-off-by: Jan van den Berg <koozz@linux.com>
When prerelease is given as a parameter with the value 'beta', the version would look like: x.y.z-beta.1 Fixes: convco#90 Signed-off-by: Jan van den Berg <koozz@linux.com>
When prerelease is given as a parameter with the value 'beta', the version would look like: x.y.z-beta.1 Fixes: convco#90 Signed-off-by: Jan van den Berg <koozz@linux.com>
When prerelease is given as a parameter with the value 'beta', the version would look like: x.y.z-beta.1 Fixes: #90 Signed-off-by: Jan van den Berg <koozz@linux.com>
Is your feature request related to a problem? Please describe.
I can't properly create the beta versions of my project.
Describe the solution you'd like
Manage pre-release depending on the current branch and a list of the pre-release branches in a config file.
Describe alternatives you've considered
Instead of getting the pre-release channel (for example
beta
) with the config and the current branch, the user could give the channel in theversion
sub-command.Additional context
Here is how semantic-release handle it: https://github.com/semantic-release/semantic-release/blob/cd6136d67ee83b262a34dd7a230e1e3ae4799ed0/docs/usage/workflow-configuration.md#pre-release-branches
The advantage of this tool over semantic-release (in my opinion) is that you just calculate the next version and change-log file when semantic-release goes to far.
The text was updated successfully, but these errors were encountered: