Skip to content
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

Closed
taorepoara opened this issue Nov 4, 2022 · 2 comments · Fixed by #105
Closed

Handle pre-release channels #90

taorepoara opened this issue Nov 4, 2022 · 2 comments · Fixed by #105
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@taorepoara
Copy link

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 the version 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.

@taorepoara taorepoara added the enhancement New feature or request label Nov 4, 2022
@hdevalke
Copy link
Collaborator

hdevalke commented Nov 4, 2022

so what you want is to enchance the .versionrc version file to include:

branches:
  - master
      name: beta
      prerelease: true
  - alpha-branch
      name: alpha
      prerelease: true

which then adds to the version 1.0.0-beta.1 or 1.0.0-beta.2 .. or 1.0.0-alpha.1 .. depending on the branch convco version is ran.

When the pre-release is set to false it would then ignore this and just set the version to 1.0.0?

Another option would just to add the property prerelease: <name> in the .versionrc file. As this could be changed easily in the branch. E.g. in master this could be prerelease: beta and in alpha-branch this could be pre-release: alpha.

or would it be better to provide convco version --prerelease beta which would imply convco version --bump --prerelease beta and let it up to the ci script/pipeline to set the right version e.g. based on a label of the pull request or in any other way?

What do you think is the most convenient way?

@taorepoara
Copy link
Author

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: convco version --prerelease beta to get the latest beta prerelease of the current branch and convco version --bump --prerelease beta to get the next beta prerelease.

@hdevalke hdevalke added the good first issue Good for newcomers label Nov 8, 2022
koozz added a commit to koozz/convco that referenced this issue Jan 20, 2023
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>
koozz added a commit to koozz/convco that referenced this issue Jan 20, 2023
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>
hdevalke pushed a commit to koozz/convco that referenced this issue Jan 23, 2023
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>
hdevalke pushed a commit that referenced this issue Jan 23, 2023
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants