[GH-ISSUE #696] [Question] What is the logic behind appending <x.y.z> part to prerelease versions #3186

New Issue

GiteaMirror · 2026-04-25T17:30:30-05:00

GiteaMirror commented

2026-04-25 17:30:30 -05:00

Originally created by @RomanDavlyatshin on GitHub (May 4, 2021).
Original GitHub issue: https://github.com/semver/semver/issues/696

The example:

Imagine we have a previous version being 1.0.0;
Work on multiple features is in progress: feature/a, feature/b, feature/c.
Each branch is developed and tested in isolation. In order to facilitate a consistent testing process, we create prerelease versions from each branch (x.y.z-feature-a.0, x.y.z-feature-a.1, ...) each one representing a certain patch/fix introduced during back-and-forth work on a feature.
When features are done, release branch is created, e.g. release 1.1.0, which will include x.y.z-feature-a.999, x.y.z-feature-b.100 and x.y.z-feature-c.42.
Feature feature/c gets postponed to a later release, but now its x.y.z part is incorrect because it's pointed to a release we expected to merge it into.

Question 1: Why a prerelease <major.minor.patch> part is pointing towards a future version, rather than the one prerelease is based on?
It seems to me that making x.y.z part of a prerelease version point to a "previous" version it's based on makes more sense, than pointing it to some arbitrary release, that might change versions at any time.

The example:
When creating a prerelease semver infers version from the current one, and the following example (using Semver's npm package)

console.log(semver.parse('1.0.0').inc('prerelease', 'new-feature-name').version)

yields

1.0.1-new-feature-name.0

as you can see, besides adding a "prerelease" part, Semver incremented a PATCH version.

Questions 2: What is the reasoning behind incrementing a PATCH version by default?
Questions 3: Can one force Semver to bump a MINOR version, in a case when changes introduced in prerelease will add a new feature? Or force a MAJOR version bump, when changes will introduce a breaking change?

Originally created by @RomanDavlyatshin on GitHub (May 4, 2021). Original GitHub issue: https://github.com/semver/semver/issues/696 **The example**: 1. Imagine we have a previous version being `1.0.0`; 2. Work on multiple features is in progress: `feature/a`, `feature/b`, `feature/c`. 3. Each branch is developed and tested in isolation. In order to facilitate a consistent testing process, we create prerelease versions from each branch (`x.y.z-feature-a.0`, `x.y.z-feature-a.1`, ...) each one representing a certain patch/fix introduced during back-and-forth work on a feature. 4. When features are done, release branch is created, e.g. release `1.1.0`, which will include `x.y.z-feature-a.999`, `x.y.z-feature-b.100` and `x.y.z-feature-c.42`. 5. Feature `feature/c` gets postponed to a later release, but now its `x.y.z` part is incorrect because it's pointed to a release **we expected** to merge it into. **Question 1:** Why a prerelease `<major.minor.patch>` part is pointing towards a **future** version, rather than the one prerelease is **based on**? It seems to me that making `x.y.z` part of a **prerelease** version point to a "previous" version it's **based on** makes more sense, than pointing it to some arbitrary release, that might change versions at any time. ____________________________________________________________________________________________________________________ **The example**: When creating a prerelease semver infers version from the current one, and the following example (using Semver's npm package) ``` console.log(semver.parse('1.0.0').inc('prerelease', 'new-feature-name').version) ``` yields ``` 1.0.1-new-feature-name.0 ``` as you can see, besides adding a "prerelease" part, Semver incremented a PATCH version. **Questions 2**: What is the reasoning behind incrementing a PATCH version by default? **Questions 3**: Can one force Semver to bump a MINOR version, in a case when changes introduced in `prerelease` **will** add a new feature? Or force a MAJOR version bump, when changes **will** introduce a breaking change?

GiteaMirror closed this issue

2026-04-25 17:30:30 -05:00

GiteaMirror commented

2026-04-25 17:30:32 -05:00

@jjlharrison commented on GitHub (May 4, 2021):

I think this issue relates to https://github.com/npm/node-semver, not this repository.

@jjlharrison commented on GitHub (May 4, 2021): I think this issue relates to https://github.com/npm/node-semver, not this repository.

GiteaMirror commented

2026-04-25 17:30:32 -05:00

@ljharb commented on GitHub (May 4, 2021):

A prerelease is “pre” a release - before it. Linguistically speaking nothing else would make sense for that name.

@ljharb commented on GitHub (May 4, 2021): A prerelease is “pre” a release - before it. Linguistically speaking nothing else would make sense for that name.

GiteaMirror commented

2026-04-25 17:30:32 -05:00

@RomanDavlyatshin commented on GitHub (May 4, 2021):

@jjlharrison I've encountered the same behavior with npm version, so I assumed it's a trait of a specification, not implementation. If I am wrong, I would gladly close that issue and re-open it to another rep.

@RomanDavlyatshin commented on GitHub (May 4, 2021): @jjlharrison I've encountered the same behavior with `npm version`, so I assumed it's a trait of a specification, not implementation. If I am wrong, I would gladly close that issue and re-open it to another rep.

GiteaMirror commented

2026-04-25 17:30:33 -05:00

@RomanDavlyatshin commented on GitHub (May 4, 2021):

A prerelease is “pre” a release - before it. Linguistically speaking nothing else would make sense for that name.

@ljharb I agree, that statement makes sense. In that case, "prerelease" might be a bad way to put it.
I guess I'm asking for a suggestion of naming versions that contain "WIP features".
AFAICT Semver does not suggest any straightforward approach for that, besides putting feature name in the "prerelease" part, but the aforementioned issues arise.

@RomanDavlyatshin commented on GitHub (May 4, 2021): > A prerelease is “pre” a release - before it. Linguistically speaking nothing else would make sense for that name. @ljharb I agree, that statement makes sense. In that case, "prerelease" might be a bad way to put it. I guess I'm asking for a suggestion of naming versions that contain "WIP features". AFAICT Semver does not suggest any straightforward approach for that, besides putting feature name in the "prerelease" part, but the aforementioned issues arise.

GiteaMirror commented

2026-04-25 17:30:33 -05:00

@ljharb commented on GitHub (May 4, 2021):

@RomanDavlyatshin there isn’t anything in semver for that besides a prerelease - the version it’s based on is irrelevant, only the version it’s targeted to be released as is useful.

@ljharb commented on GitHub (May 4, 2021): @RomanDavlyatshin there isn’t anything in semver for that besides a prerelease - the version it’s based on is irrelevant, only the version it’s targeted to be released as is useful.

GiteaMirror commented

2026-04-25 17:30:34 -05:00

@RomanDavlyatshin commented on GitHub (May 4, 2021):

@ljharb yes, and that is what causing the issue, in a scenario when the feature gets postponed to another release. (And that confuses me 🤔 )
I guess I'll wait for a day or two for comments on the issue, in case anybody else got something to say on that one and then will close it.
Disclaimer: I am not suggesting that there is anything wrong with Semver, I'm just looking for a way to resolve the issue described above. So any comments/ideas are greatly appreciated.

@RomanDavlyatshin commented on GitHub (May 4, 2021): @ljharb yes, and that is what causing the issue, in a scenario when the feature gets postponed to another release. (And that confuses me 🤔 ) I guess I'll wait for a day or two for comments on the issue, in case anybody else got something to say on that one and then will close it. **Disclaimer**: I am not suggesting that there is anything wrong with Semver, I'm just looking for a way to resolve the issue described above. So any comments/ideas are greatly appreciated.

GiteaMirror commented

2026-04-25 17:30:36 -05:00

@jjlharrison commented on GitHub (May 4, 2021):

@jjlharrison I've encountered the same behavior with npm version, so I assumed it's a trait of a specification, not implementation. If I am wrong, I would gladly close that issue and re-open it to another rep.

npm version uses node-semver too.

@jjlharrison commented on GitHub (May 4, 2021): > @jjlharrison I've encountered the same behavior with `npm version`, so I assumed it's a trait of a specification, not implementation. If I am wrong, I would gladly close that issue and re-open it to another rep. `npm version` uses node-semver too.

GiteaMirror commented

2026-04-25 17:30:36 -05:00

@ljharb commented on GitHub (May 4, 2021):

@RomanDavlyatshin then it'd just go in a different prerelease. There's never a guarantee that a version will contain everything that a prerelease of it contains.

@ljharb commented on GitHub (May 4, 2021): @RomanDavlyatshin then it'd just go in a different prerelease. There's never a guarantee that a version will contain everything that a prerelease of it contains.

GiteaMirror commented

2026-04-25 17:30:37 -05:00

@RomanDavlyatshin commented on GitHub (May 5, 2021):

There's never a guarantee that a version will contain everything that a prerelease of it contains.

@ljharb That is exactly what I am pointing to 😃
I simply dislike the fact, that the version name (x.y.z-feature.n) will have to be changed "midway", to something like x.W.z-feature-n.
This is annoying because branches and artifacts (named after the version name) with new names will no longer consistently reflect the whole history of a feature.

One could drop a release name from the feature branch name altogether. But in a long project, that will lead to feature branches old and new piling up without context.

I think this is not an issue with Semver per se, after all;
As there are no more suggestions, I'm closing the issue. Thank you, everybody 👍 .

@RomanDavlyatshin commented on GitHub (May 5, 2021): > There's never a guarantee that a version will contain everything that a prerelease of it contains. @ljharb That is exactly what I am pointing to 😃 I simply dislike the fact, that the version name (`x.y.z-feature.n`) will have to be changed "midway", to something like `x.W.z-feature-n`. This is annoying because branches and artifacts (_named after the version name_) with new names will no longer consistently reflect the whole history of a feature. One _could_ drop a release name from the feature branch name altogether. But in a long project, that will lead to feature branches old and new piling up without context. 1. I think this is not an issue with Semver per se, after all; 2. As there are no more suggestions, I'm closing the issue. Thank you, everybody 👍 .

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#3186