mirror of
https://github.com/semver/semver.git
synced 2026-07-11 03:53:53 -05:00
[GH-ISSUE #95] you shouldn't allow a build version without a pre-release version #6057
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#6057
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 @dtudury on GitHub (May 5, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/95
my understanding is that the versions progress from inception to release goes something like this (it's totally possible I'm missing something):
pre-release versions come before non-pre-release versions and build versions come after non-build versions. I guess my question is: why would you ever use a build version without a pre-release version? the spec seems to allow it.
my reading of the spec says 1.0.0 is before 1.0.0+build.1. But what could 1.0.0+build.1 possibly be? is it a release? if it is and it's not the same as 1.0.0 then it must be updated to at least 1.0.1. if it's not released then it's a pre-release and should be labeled as such. without mandating a new pre-release version for build versions you're implying that 1.0.0+build.1 is effectively 1.0.1-pre-alpha+build.1 but people will treat them like patches. people already do: 1.0.0-1 comes after 1.0.0 in joyent/nodejitsu-land (and I followed one of their links to find the spec)
in one line: you are always working towards the next release
@colin-haber commented on GitHub (May 5, 2013):
I think you're misunderstanding the concept of build metadata. It's not as much a version like the rest of the SemVer string, nor is it usually going to be made for human eyes. The build ID is intended (though not required) to be generated by build scripts or programs, like CI systems, for mostly internal reference.
So, think more like:
Different build meta schemes will use different things, but my main point is that the build metadata allows automatically built projects to have a permanent reference to them by SemVer, as well as by whatever other methods are provided.
@dtudury commented on GitHub (May 5, 2013):
Thanks for the quick reply! Regarding your example:
I don't understand how that would have happened. they were both called 1.0.0-rc.1+build.2013-04-03.x when worked on internally. then one got promoted to release at which point it became 1.0.0+build.2013-04-03.x. why would a second one get promoted to the same release? either it's the same or it's different.
maybe the spec should say build versions on non-pre-release builds are informational only and also that they must be unique? This doesn't prohibit automatic generation. It prohibits people breaking the intention of the spec.
@dtudury commented on GitHub (May 6, 2013):
The issue is clear in my head but when I try to explain it it seems to become unnecessarily weird and complicated.
Engineers only create pre-release versions. When a pre-release is deemed worthy, the pre-release tag is dropped and it becomes the release. This can only happen once for each x.y.z version.
@Tieske commented on GitHub (May 6, 2013):
maybe some, maybe many, but certainly not all. Current state of build meta data in semver makes it as flexible as possible, for everyone to use at their own liking. There is no use in restricting it.
@dtudury commented on GitHub (May 6, 2013):
what I mean is it's pre-release until it's released (and if someone's working on it, it hasn't been released). once it's released no other release can ever share the same version. if 1.2.3+4 is different than 1.2.3+5, then two releases share the same x.y.z version. that makes the +r effectively a second patch number.
actually, I guess that works... for release version: x.y.z+r the patch version is "z+r". is that what I was missing?
@Tieske commented on GitHub (May 6, 2013):
say a toolchain is in use, CI server, whatever. Now the toolchain gets upgraded, then tests start breaking. The source wasn't modified, so the version is the same. But to help diagnose the problem it is very helpful to know the buildnumber, so it can be determined with which toolchain it was build and whether something changed there that made it break.
To the core of your comment: not necessarily all versions need to be released, nor all builds. I think that is the implicit assumption you make.
@dtudury commented on GitHub (May 6, 2013):
I'm not opposed to build numbers. in fact, I'm really excited about build numbers (certain products shoe-horned them into the last spec and it wasn't great). I think all I really want is a definitive answer to "can I release 1.2.3+4 and then later release 1.2.3+5 of the same product?".
these are my assumptions:
@Tieske and @dgn1nja, thanks for your responses, I'm playing devil's advocate a little, please let me know if my friendly antagonism is unhelpful (or unfriendly :)
@colin-haber commented on GitHub (May 6, 2013):
In regards to whether 1.2.3+4 and 1.2.3+5 are acceptable releases of the same product, think of it this way. As a consumer of your API or library, I am almost never interested in your build ID. It has no effect on compatibility or stability whatsoever. To me, those are effectively the same, and you would probably never have released both of them publicly.
However, if you had a nightly build system, there might be the case where you nightly-released 1.2.3+4 one night, and 1.2.3+5 the next one. Like I said, build meta is mostly for automated systems.
So, are they acceptable? Yes. Would you usually see both of them as public, stable releases? No.
@dtudury commented on GitHub (May 6, 2013):
@dgn1nja so the definitive answer is "yes, the spec won't prohibit it, but probably you shouldn't do it".
I know it's not supposed to but... no offense, I don't know you well enough to trust that you didn't break something in 1.2.3+5 that worked in 1.2.3+4. (I wouldn't trust myself that far in fact :) for a project with lots of complicated and fragile dependencies, I'd demand version 1.2.3+4
also, you're saying there are 3 kinds of builds: pre-releases, releases, and public-stable-releases? if that's true I think the pre-release version should be repurposed for non-public-stable-release versions. it's important to be able to differentiate public stable releases from everything else.
regardless, from your example, if you're working toward 1.2.3, I think you should have your nightly build output something like _1.2.3-nightly+2013-05-06_
@Tieske commented on GitHub (May 6, 2013):
no, the anser is yes, without a 'but'. SemVer guarantees compatibility within the rules as set forward on major/minor/patch numbers.
That is exactly what it is: trust. If you wouldn't trust the change in buildnumber, then why would you trust backward compatibility of 3.2.1 with 3.2.0 ? If you go down that path, than nothing can be trusted.
@dtudury commented on GitHub (May 6, 2013):
@Tieske yes, trust, exactly.
according to the 4th rule:
A build version changing a new version and is the same as a patch version changing. It ought to function the same, but it's still a change. For release version: x.y.z+r the patch version is "z+r"
@Tieske commented on GitHub (May 6, 2013):
Nope. Not a change. Source didn't change. Unless you want to start a big debate on the form in which a "package" must be distributed (binary, source, compressed, etc.) to be made part of semver.
There is a line somewhere, common practice says source code. This is getting to a nitpicking level by now.
@colin-haber commented on GitHub (May 6, 2013):
@Tieske I agree. Either way, this issue should be closed.
@Tieske commented on GitHub (May 6, 2013):
@dgn1nja agree!
@dtudury commented on GitHub (May 6, 2013):
I don't think it's nitpicking, I didn't know that source couldn't change. if it is in the spec it's implied.
@Tieske @dgn1nja, you're right, this has become a different issue.
@Tieske @dgn1nja @mojombo @Haacked do you think it's worth opening an issue to make that explicit? ("should explicitly state that source can't change between releases who's only difference is build version") (or do you want me to go away? :)
I feel confident that as it stands package managers will ignore it and other people will miss it. you'll find people releasing 0.0.0+100 as a patch to 0.0.0+99
@Tieske @dgn1nja thanks so much for your help! sorry to come across as nit-picky, I (obviously) didn't understand a couple of points in the spec
@Tieske commented on GitHub (May 6, 2013):
that is non confirming to semver (except that it is in the 0.x.x range which is special in semver, but that is besides your point). And regarding my opinion on pre-release, see #30
@dtudury commented on GitHub (May 6, 2013):
@Tieske no, yeah, I know now. but I didn't before... (I wasn't being hypothetical) :)
in the past I let jitsu (a deployment script) auto-increment my version and I did exactly that (0.0.0-99 -> 0.0.0-100). Which was fine because npm (a package manager) doesn't allow any dashes so I was forced to update the patch version before publishing it. after the 2.0.0 spec auto-incrementing will likely occur after a plus and package managers will accept versions with pluses. This makes the automatic policing that helped me difficult.
actually... I guess it could still work; the error would be something like "redundant release 0.0.1+100: 0.0.1 was already published (previous build named: 0.0.1+99)"
@dtudury commented on GitHub (May 9, 2013):
@Tieske hey look at that... 2.0.0-rc.2 explicitly says build metadata doesn't differentiate versions. looks like that's what you were fighting for in #30 . well done! seems to solve the only problem (misinterpreted ambiguity) I could see