mirror of
https://github.com/semver/semver.git
synced 2026-07-11 06:53:03 -05:00
Minor incrementation in 'patch-hotfix after prerelease@preminor' #406
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#406
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @askirmas on GitHub (Apr 9, 2020).
Scenario 1:
Scenario 2 is Scen.1 without hotfix.
Sc1 will produce 0.1.0 -> 0.2.0-0 -> 0.2.0 -> 0.3.0
Sc2 0.1.0 -> 0.2.0-0 -> 0.2.0
This causes misunderstood in communications - somebody expected next with certain functionality but it is not what we announced.
Changing prerelease to be prepatch looks not good. Will produce 0.1.0 -> 0.1.1-0 -> 0.1.1 -> 0.2.0. But logical 0.1.1-0 related to 0.2.0 and no relation to 0.1.1.
Any ideas/advices?
@ljharb commented on GitHub (Apr 9, 2020):
Why would a patch cause
v0.2.0-0to becomev0.2.0rather than justv0.2.0-1?@askirmas commented on GitHub (Apr 9, 2020):
Because it is patch, not a prerelease. 3rd number PATCH should be incremented
@ljharb commented on GitHub (Apr 9, 2020):
Right, but
v0.2.0is a minor release - if it's a patch to the prerelease, it'd be a new prerelease version. If releasingv0.2.0was intentional, then it's correct to have the next minor release bev0.3.0.There's no value in making sure that different scenarios result in the same version list, because they simply often won't - that's why they're different scenarios.
@askirmas commented on GitHub (Apr 10, 2020):
No, 'patch of prelease' is something senseless. Patch (really - hotfix in not semver terms) for latest stable release. And prerelease to future minor.
Logically and in ideal situation will be
v0.1.0->v0.1.1->v0.2.0-0->v0.2.0. In reality (especially in short sprints) can happen that prerelease (of future) pushed before hotfix (of present). And tags list is changed tov0.1.0->v0.2.0-0->v0.1.1->v0.2.0. But it couldn't be at all because of the only possible action is increment. That's the point - to have possibility to 'increment' fromv0.2.0-0tov0.1.1. Basically it means like extension of my first sentence - prerelease 'state' can be only increased or resolved/stabilized. For stable actions (major/minor/patch) incrementor should behave like unstable tags don't exist at all. Really, sounds weird 'minor update of prerelease'.To be 100% correct - after hot fix immediately should be pushed new prerelease
v0.1.0->v0.2.0-0->v0.1.1+v0.2.0-1->v0.2.0@askirmas commented on GitHub (Apr 10, 2020):
In general my stuff sound like proposition to extend standard. Should be 2 separate lines/scales for stable (major/minor/patch) and unstable (pre-release) releases with a bit different behaviour
@askirmas commented on GitHub (Apr 10, 2020):
Despite scenarios are different in details - from 'minor' point of view (feature-oriented) they are the same. It is rather hard to announce 'our new feature is that previous feature works correctly'. But maybe it goes too far from semver idea. Program-oriented such an issue like 'redundant increment' does not exists - it is only human-wize
@ljharb commented on GitHub (Apr 10, 2020):
I’d say that you’d want to release a v0.1.1, and then release a v0.2.0-1. There’s no guarantee that prereleases comply with semver that I’m aware of.
@klehelley commented on GitHub (Apr 10, 2020):
The way I understand your question there is no need to extend the standard. SemVer describes a way to inform users of the releases of the expected compatibility between two versions, but does not say anything about version history, development process or support strategy. This is, as far as I know, on purpose as different projects have different needs and can use different tools and strategies in the regard while still adhering to SemVer if they want to.
To take your example, if I understand it correctly, you have a roadmap with the following:
Do note that I use major version 1 in the example because as per rule 4 of the SemVer specification, none of the versions in your original example should be considered stable.
So you and your team releases version 1.0.0, and then starts working on feature B. You deliver a first preview version as 1.1.0-0. Then or even before that you notice an issue with the way feature A has been implemented, and release a fixed version of 1.0.0 as 1.0.1 (after the 1.1.0-0 release). And finally you have the final 1.1.0 version released.
There is nothing wrong with that timeline. It should not be viewed as a linear history however, because it is not. You work with two somewhat independent (from the consumer point of view) branches in parallel here. There are a lot of projects in the wild that are managed like that, sometimes with several major or minor versions in active development at any one time.
I hope that helps you answer your question.
@askirmas commented on GitHub (Apr 10, 2020):
Yes, thanks