mirror of
https://github.com/semver/semver.git
synced 2026-07-11 03:53:53 -05:00
[GH-ISSUE #124] What should the version number be *between releases*? #5198
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#5198
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 @chrisdew on GitHub (Jun 20, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/124
What should the version number be between releases?
This is NodeJS/NPM specific for me, but I'm sure it's a general issue.
Currently I use odd patch version between releases, while released versions have even patch versions.
Is this a good idea?
@haacked commented on GitHub (Jun 20, 2013):
Sounds good to me. :) SemVer doesn't really prescribe odd/even patch. It just says if it's a bug fix release, increment the patch.
@rymai commented on GitHub (Jun 27, 2013):
Hi,
I think between release, the version should simply be the one of your latest released gem/package/API/whatever.
@ericdobson commented on GitHub (Jul 1, 2013):
Wouldn't the spec'd approach be to add a pre-release identifier to the planned release number? So if
1.2.3is currently released, your between release could be denoted as one of:@dwijnand commented on GitHub (Jul 3, 2013):
The way that Maven does it (for instance in the maven-release-plugin) is bump the patch number and append "-SNAPSHOT".
The way that Mercurial generates their version number when building a Mercurial release is specified here: http://selenic.com/hg/file/fbdac607bff3/setup.py#l177
and the basic effect is (unless my python-fu is weak):
@dwijnand commented on GitHub (Jul 4, 2013):
I've been thinking of this since yesterday, as I would love if this were addressed officially. Basically I would like there to be a way to define a version string that in terms of precedence is after a release: 2.3.4-rc.1 < 2.3.4 < {some version post 2.3.4}.
The reason for this is that after some release (ex. 2.3.4) I'm not sure if my future commits, in which I'll be thinking of the bug/feature/breaking-feature I'm working on, require the version to be either (if using Maven's convention) 2.3.5-SNAPSHOT, 2.4.0-SNAPSHOT or 3.0.0-SNAPSHOT. It's just "some in development version, not yet completely defined".
These not-yet-defined versions would however have lower precedence to any other version that would typically come after a v2.3.4. Therefore: 2.3.4 < {some version post 2.3.4} < 2.3.5-SNAPSHOT.
Ideally, as a hyphen (-) is used to indicate lower precedence to a release (2.3.4-rc.1 < 2.3.4), it would be nice to use a plus sign (+) to indicate after a release, for instance 2.3.4+{hash} or 2.3.4+{timestamp} or 2.3.4+{number-of-commits} (or combinations of those).
However, the plus sign is being used to indicate build metadata and then completely ignores it in terms of precedence. As such, some other symbol would have been preferable (tilde?).
So this would require changing the build metadata symbol to something else and making the plus sign be used to indicate post-release versions.
But, from reading other issue/pull request comments, I get the feeling then even if this could go into a backwards-compatibility breaking release (eg. spec v3.0.0) there's resistance to such an extensive breakage (breaking all existing projects that implement the spec).
Thoughts?
@ericdobson commented on GitHub (Jul 5, 2013):
@dwijnand I think you definitely have some interesting ideas there, I'm just not sure they're necessary for the problem you're describing.
You don't have to know what the next released version will be to use the existing approach. Just number each build according to what you've actually created. If it's a bug fix, you call that build 2.3.5-SNAPSHOT. Then if you decide to add a feature, the next build will be 2.4.0-SNAPSHOT. You can then release 2.4.0, without ever having released a version 2.3.5.
I think there could still be a place for the idea you've described. The major hurdle as I understand the project, is that it sounds like trying to dictate a new method of versioning, rather than trying to simply give order to conventions many people are already using.
@88Alex commented on GitHub (Jul 5, 2013):
I like what @rymai suggested. It sounds more natural than the other choices.
@dwijnand commented on GitHub (Jul 5, 2013):
@EricDobson The reason I can't "Just number each build according to what you've actually created" is because in many tools in the Java world, the version is a string in the build script, and any commit can be built and that version string is used to identify the version.
So, in order to not end up with two build artifacts (for instance a Java jar) with the same version string (see point 3 for the spec), as soon as you make a release you change the version to something after that release. The problem is that the moment that I release and then bump up the version I have no idea what I'm next going to release (patch/minor/major).
So, as-is, there are three ways around it:
The first approach is good because it shows that the in-development version is after the 2.3.4 release, however it's misleading because as the end release turned out to be a 2.4.0, the changes weren't just for a patch release, but a minor release.
The second approach is good because it allows for any changes to be valid as per the spec, but lacks the information of from what release it builds from. It also means that you might have a lot of 3.0.0-SNAPSHOT artifacts that were actually in-development versions for what then because release 2.3.5, 2.3.6, 2.4.0, 2.4.1, 2.5... etc, etc.
The third approach solves the issues of the previous approaches but is the most work, not something a spec should really aim for.
An approach like I described above would (IMHO) solves these issues, allows any build to be valid as-per-spec, still carry information as to which release it builds from and not be so work intensive.
[Edit: Typo in "most work approach" description]
@EddieGarmon commented on GitHub (Jul 15, 2013):
I believe your 'most work' approach is the correct approach. You shouldn't change your version until you know what has actually changed. I have an internal tool that I hope to rewrite at MonkeySpace as OSS that for .NET, builds the code, reflects the public api, and then sets the appropriate version based off changes from the last 'released' api (not last build or prerelease), updates the version info in code, then perform the build again with the correct version.
@Tieske commented on GitHub (Jul 15, 2013):
How would you do that? You can check the api signatures, but not behaviour. If you can't guarantee it I would rather stay away from this type of magic.
@EddieGarmon commented on GitHub (Jul 16, 2013):
yes signatures, including versions on each type within each signature.
if you change behavior in a method without changing the signature You Did Something Wrong™
either originally, and you are trying to fix it, or You Did Something Wrong™
@TheLudd commented on GitHub (Sep 17, 2013):
I think that there are two sides of this discussion adressed in this issue.
On question 1: IMHO the spec has already resolved this and @EricDobson is correct in his first comment here. When a project is "between releases" it is really before the next release. So the version should be [next version]-[identifier]. From that point of view this issue could be closed but it does lead to question "How do I know what the neext version will be?" which I address here:
On question 2: I agree that the "most work approach" by @dwijnand is the correct one, and here is a crazy proposal on how to practically solve it:
When version 1.0.0 is released, create 3 new branches called 2.0.0, 1.1.0 and 1.0.1. If you begin work on a patch, branch out from, or commit to, 1.0.1. If you work on a new feature, do it from/to 1.1.0 etc. When you release a patch, merge it with the minor branch and optionally the major branch and create a new branch called 1.0.2. When you release a minor version be sure to merge any unreleased patches, create a new branch called 1.2.0 and one called 1.2.1 and perhaps delete old branches. Since major releases allow for braking changes they may not want to merge from minor/patch versions, but the could certainly do so. When version 2.0.0 is released, branches 1.x.y can still be kept in version control if you want to continue to support them.
On each branch the project could have the version of that branch with a "-[identifier]" added to it.
I would appreciate thoughts and comments on this. I believe it is a "pure" approach to the problem but is it maintainable (with or without software to help perform releases and merges according to what I have written)? I also realize that my little description is far from enough to cover all the cases but is the approach a good one?
@EddieGarmon commented on GitHub (Sep 17, 2013):
Don't overwork yourself. Name your branches after the issue being tackled, solve your problem, and then figure out the appropriate version number. The spec as is, is sufficient.
@ryantheleach commented on GitHub (Jun 8, 2017):
Sure, but continuous integration / test builds going out to users dictates that theres some sort of nightly / bleeding branch for the users to test with. unless we increment the version for every nightly, (in which case they are going to rise extremely rapidly) then it's going to be hard to maintain semver unless people are extremely vigilant.
An example.
We have a bleeding branch that was 6.0.0 that changed to 6.1.0-snapshot, then was promoted to 7.0.0 due to major changes.
A hotfix comes out, but our bleeding is already forward, it gets ported to stable, which had also been changed to 6.1.0-snapshot, but hadn't yet had any changes applied. It was applied to the 7.0.0 bleeding/nightly series.
we can either go backwards to 6.0.1 on our stable, or go forward to 6.1.0 without any new features.
meanwhile our bleeding/nightlies never saw a 6.1? that seems odd.
@jwdonahue commented on GitHub (Dec 2, 2017):
@chrisdew, I believe @Haacked answered your question in the affirmative. Unless you have any further questions regarding your odd/even question, please close this issue.
@silkentrance commented on GitHub (Dec 7, 2017):
@jwdonahue please close as it is counter productive.
@jwdonahue commented on GitHub (Oct 7, 2018):
@chrisdew, can you please close this issue? I don't have the sauce and we're trying to reduce the number of none actionable open issues. Thank you.
@silkentrance commented on GitHub (Oct 25, 2018):
@chrisdew you can always label/tag your version, e.g. -SNAPSHOT, as in the maven world. However, if you are going to release such interim versions, you must further qualify the tag, e.g. -SNAPSHOT-1, since npm does not allow you to replace an existing version. maybe by a built number when using a CI?
@Tieske commented on GitHub (Oct 25, 2018):
@silkentrance you had me at "if you are going to release such interim versions", if you're releasing them, they are no longer interim versions...
@silkentrance commented on GitHub (Oct 25, 2018):
@Tieske well, with maven you can always deploy such interims, called snapshots, to your configured snapshot release repository. with npm this is different, since it does not support such a concept. as such, you need to qualify the interim release tag by a distinct number.
@Tieske commented on GitHub (Oct 25, 2018):
from semver perspective those are implementation details. If anything they should be build-metadata in semver parlance imo.
@silkentrance commented on GitHub (Oct 25, 2018):
Which is why we should close this as it is process related and already supported by the semver spec.
@jwdonahue commented on GitHub (Jan 15, 2020):
@chrisdew, please close this issue at your earliest possible convenience.
@jwdonahue commented on GitHub (Jun 9, 2020):
My thinking on this problem has been evolving. We all know that spec says bump the patch or minor field and attach a prerelease tag to it. I've recently (over the past couple of years) been coming around to the idea that there is no "in-between-release version". Releases are synonymous with publications. SemVer versions should not be applied to any unreleased intermediary products what-so-ever. That implies no version strings in source code, but I digress.
Since SemVer version strings are only applied to publications (ie, public releases), all that is left to decide is exactly what comprises a publication? My answer to that question is; it depends on your workflows. My personal favorite approach is just use build numbers and other build meta identifiers for everything that is "released" internally, such as from the build server to the test automation labs and that sort of thing, then only apply a SemVer version to bits that deemed worthy of releasing to the public (early flight tests, betas, RC's, etc) and what version we put on those, depends on what you've changed and whether it breaks anything.
@jwdonahue commented on GitHub (Jun 9, 2020):
@alexandrtovmach, can we slap a "question answered" tag on this thread and close it please?
@alexandrtovmach commented on GitHub (Jun 10, 2020):
Closed as resolved, thanks everyone for contribution 👍
@chrisdew If you still have any questions, feel free to re-open