toolshed/abra
4
2
Fork 18
Code Issues 32 Pull Requests 3 Packages Releases 40 Activity

refactor: improved version choice flow

Browse Source
This commit is contained in:
cellarspoon
2021-12-28 03:16:23 +01:00
parent 26a11533b4
commit 1fd0941239
3 changed files with 74 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
cli/internal/recipe.go
View File

@ -13,10 +13,27 @@ import (
// PromptBumpType prompts for version bump type
func PromptBumpType(tagString string) error {
if (!Major && !Minor && !Patch) && tagString == "" {
fmt.Printf(`semver cheat sheet (more via semver.org):
major: new features/bug fixes, backwards incompatible
minor: new features/bug fixes, backwards compatible
patch: bug fixes, backwards compatible
fmt.Printf(`
You need to make a decision about what kind of an update this new recipe
version is. If someone else performs this upgrade, do they have to do some
migration work or take care of some breaking changes? This can be signaled in
the version you specify on the recipe deploy label and is called a semantic
version.
Here is a semver cheat sheet (more on https://semver.org):
major: new features/bug fixes, backwards incompatible (e.g 1.0.0 -> 2.0.0).
the upgrade won't work without some preparation work and others need
to take care when performing it. "it could go wrong".
minor: new features/bug fixes, backwards compatible (e.g. 0.1.0 -> 0.2.0).
the upgrade should Just Work and there are no breaking changes in
the app and the recipe config. "it should go fine".
patch: bug fixes, backwards compatible (e.g. 0.0.1 -> 0.0.2). this upgrade
should also Just Work and is mostly to do with minor bug fixes
and/or security patches. "nothing to worry about".
`)
var chosenBumpType string