Prerelease support

[nbrugger-tgm]

It is common for a Software lifecycle to Release prereleases or snapshot, dev or beta builds.

Therefore it would be Essential that a uplift supports such features to be used in this kind of Software.

Prereleases are a Part of the Semver spec.

1.2.3-rc.12.5
1.2.3-beta
1.2.3-dev.264

While as a User of semver you can use everything as pre build number (for example commit hash) but in the case of a standardized Software like uplift, simple increments should do the Trick.

A few examples of how it would work (this build number Generation strategy is copied from the python comitizzen project)

1.2.3 (breaking change, beta Release) 2.0.0-beta
1.2.3 (non breaking change, beta Release)
1.3.0-beta
1.2.3-beta (Patch, beta Release) 1.2.3-beta.2
1.2.3-beta (no changed, full release) 1.2.3

Be aware that I do not propose that this isn't the best way to handle it, as while it is convenient to have more Iteration of a Single beta Version that to have a new Version every change there are problems.

Possible problems

How would you Deal with this?

v1.2.3
(minor changes beta Release)
v1.3.0-beta
(breaking change, beta Release)
??? v1.3.0-beta.2, v2.0.0-beta, v2.0.0-beta.2???

While I would say 2.0.0-beta is the right answer It would t be quite easy to computer.

One would need to find out that the Jump from 1.2.3 to 1.3.0 is a "Feature" jump and therefore not sufficient to Cover a "breaking change jump.

Another way simpler solution would be to just append whatever the User wants after the minus (as long as semver compilant) and dont give a ** about it for computing the next Version number

[ga-paul-t]

@nbrugger-tgm you have raised some valid points here. I will take a look at the commitizzen project.

The initial idea behind uplift was to provide a mechanism for supporting conventional commits in a CI pipeline. Ideally with a focus towards continuous delivery/deployment, where the presence of a feat! (breaking change), feat or fix conventional commit would trigger a release i.e. by tagging the repository. For my personal workflow, when writing Go applications, the presence of a new tag would trigger goreleaser to build, package and distribute the binary.

In a way, it tries to encourage smaller, frequent commits by developers, or teams of developers.

But this may not always be the most ideal solution. And does alienate other ways of working. I'll dedicate some time to looking into the approach you have suggested above.

[nbrugger-tgm]

Also, this is not a rant but just ideas for improvement.

I think the main reason why a person would want to have pre-releases is a scenario where you want to create multiple breaking changes but not go from 2.3.4 to 7.0.0-rc with 3-6.0.0-rc "useless created.

Because how i see it, with the current model you have in mind a mayor bump 2.3.4 to 3.0.0 can not have a pre-release because how i understood it, the workflow would go like this :

2.3.4 -> 3.0.0-rc -> 4.0.0-rc -> 4.1.0

[ga-paul-t]

Apologies think I misunderstood your initial use case. It would make much more sense to have this exposed as a CLI flag for running ad-hoc processes. I have been using uplift as a standalone process mainly without invoking individual parts of it through the different commands.

My long term target is to shrink the dependency on the config as much as possible. I would prefer the config to be an exception rather than the default behaviour (auto-detection of file types when bumping as an example). Which does contradict my previous comment 😄

It will be easy to add a flag such as --prerelease as a global CLI flag that cascades through all of the other uplift commands

[ga-paul-t]

I am happy for any comments on possible improvements and ideas

[ga-paul-t]

Yes, you are right. The way uplift was designed initially was for a workflow of small frequent commits with each triggering a release that could then be cascaded into production through continuous deployment/delivery

[ga-paul-t]

Raised new issue to capture this, #65