Build Number Precedence is Backwards #51

Closed
jeffhandley opened this Issue Oct 23, 2012 · 74 comments

Projects

None yet
@jeffhandley
Contributor

I just read through the issues and discussions on CodePlex for NuGet, and it seems like the expectation is that build number precedence would be backwards from how it is defined today, allowing daily builds to march toward a prerelease version.

This discussion has the most activity: http://nuget.codeplex.com/discussions/277189

I really feel like we should reverse the precedence so that build numbers would allow you to work toward a prerelease version. That would simplify the logic to the following:

  1. Build numbers march toward a prerelease version
  2. Prerelease versions march toward a stable release

Presently, the spec has it defined as:

  1. Prerelease versions march toward a stable release.
  2. Build numbers allow you to put out newer builds of a stable or prerelease version without changing its version.

I guess I’m just not sure why you’d need to have additional builds after a version. Once a version is released, it’s done; new builds should be a new version. If there was something wrong with the version that was released and you need to put out a new build, then it’s a Patch to the broken version and therefore the patch number should be increased.

And perhaps, we should limit build numbers to prerelease versions, as I haven't yet seen evidence for build numbers to be needed on stable versions. If we allow build numbers on stable versions and a user has said they want to opt into "Prerelease" versions, does that mean they also get build-number versions? If they don't want prerelease versions, do they need to opt in/out of build numbers?

Here are some examples that are called out, and discussion participants unanimously agree that build numbers march toward a prerelease version.

EddieGarmon

  1. 1.0.1alpha-0001
  2. 1.0.1alpha-0002
  3. 1.0.1alpha
  4. 1.0.1alpha2
  5. 1.0.1beta-0003
  6. 1.0.1beta-0004
  7. 1.0.1beta
  8. 1.0.1

Ferventcoder (+1 from xavierdecoster despite that he had previously laid out the ordering as shown in the spec)

  1. 1.0.0-alpha.001
  2. 1.0.0-apha
  3. 1.0.0-alpha1.001
  4. 1.0.0-alpha1.002
  5. 1.0.0-apha1
  6. 1.0.0-beta
  7. 1.0.0-rc
  8. 1.0.0

EddieGarmon

  1. 1.0.1alpha-ci-20111026-1 <-- CI Build
  2. 1.0.1alpha-ci-20111026-2 <-- CI Build
  3. 1.0.1alpha-ci-20111026 <-- Nightly
  4. 1.0.1alpha-ci-20111027-1 <-- CI Build
  5. 1.0.1alpha

Haacked

  1. 1.0.1alpha~001
  2. 1.0.1alpha~002
  3. 1.0.1alpha~003
  4. 1.0.1alpha

ferventcoder

  1. 1.0.0alpha~001
  2. 1.0.0alpha
  3. whoops - 1.0.0alpha.1

ferventcoder

  1. 1.2.10alpha~001
  2. 1.2.10alpha~001.1 (fix of build 001 alpha package, not contents)
  3. 1.2.10alpha
  4. 1.2.10alpha.1 (fix of alpha package, not contents)
  5. 1.2.10
  6. 1.2.10.1 (fix of 1.2.10 package, not contents)

EddieGarmon

  1. 1.2.10alpha~001
  2. 1.2.10alpha~002 (fix of build 001 alpha package metadata, not contents)
  3. 1.2.10alpha~003 (same package metadata, new contents)
  4. 1.2.10alpha (ideally this is a repackage of alpha~003 with just package metadata edits, same contents)
  5. 1.2.10
  6. 1.2.10.1 (fix of 1.2.10 package or contents)

EddieGarmon

  1. 1.2.10-alpha120111017 (CI Build)
  2. 1.2.10-alpha220111017 (CI Build)
  3. 1.2.10-alpha~3
  4. 1.2.10-alpha420111018 (CI Build)
  5. 1.2.10-alpha~5
  6. 1.2.10-alpha
@fearthecowboy

I actually thought this was pretty clear in the semver spec.

I liked the usage of + or - to indicate what side of the version you were on--frankly, it allows the most flexibility, and purpose to be determined by the publisher/developer.

I guess I’m just not sure why you’d need to have additional builds after a version

Because, diversity is a wonderful thing, and not everyone does everything the same. Having it support both ways as the spec now is is really nice, because you don't have to make judgements on how others do development, yet you can support them in their way.

@fearthecowboy

Furthermore, the existing spec supports easily translating to a four-part version (ie, what Windows uses for it's version numbers, and .NET versioning)... to only allow build numbers to creep up to a version would break that.

@xavierdecoster

I also think that build numbers don't make sense on releases.

Without a build number, the smallest release would be a patch release, which MUST be incremented when shipping backwards-compatible bugfixes / internal changes. I can't think of any smaller meaningful release...

There's a lot of variation and there's the four-part legacy versioning strategy. Having releases without a build number would semantically be the same as having a version with build number 0.

However, adding this 0 would complicate sorting algorithms defining version precedence as explained in the above discussion. Not having the build number could be treated differently from having a build number, even if it is 0. This is of key importance for tools such as NuGet to support package updates from e.g. CI builds through pre-releases towards releases.

Note: there's also the notion of package version vs assembly version. Maybe the package version could strip of the build number?

@Haacked
Collaborator
Haacked commented Oct 23, 2012

I think the idea that build numbers "build up to a release" is applying a semantic on it that doesn't make sense for build numbers. That's not the semantic that should be implied.

Think of a build number as simply metadata about a version. It's a build artifact. The semantic of the build number should be only that it tells you information about when that particular version was created, typically stamped by a build machine and tells you which build it was. But as it's metadata, it's flexible enough to have whatever information you want in it really.

Thus Major, Minor, and Patch define the version of the software, while Build defines a specific build of that software version.

For example, if you have a nightly build, and you didn't make any changes in a few days, you might have three different builds. They're all the exact same bits in the software, but they're stamped with different build numbers. Typically, folks stamp them with something representing a date so they know when the specific thing was built.

As another example, suppose you increment the build number on every compilation. 1.0.0+007 tells you that this is the 7th compilation of version 1.0.0. If the +007 implied a version less than 1.0.0, how would you know what version that build label labels? It's not self-contained in that case.

From a package manager perspective, I would expect package managers would ignore the build number when determining things like version conflicts. For example, a public package manager should not allow two packages wit the following: 1.0.0+001 and 1.0.0+002 in the feed. It should be considered a conflict and the attempt to upload the latter one should require incrementing the patch version. Using build numbers should not be a way around the SemVer versioning scheme. Some package managers allow replacing versions. In that case, you could replace the first with the second. But having both would be bad.

@jeffhandley
Contributor

For public-consumption of packages, I can understand that build numbers are just metadata that don't matter. But for internal development where teams are sharing packages, we should definitely allow the package manager to "upgrade" from one build to another. In order for that to work, whatever repository the packages get stored in must allow multiple builds of the same version, and the package manager client will need to understand precedence between them.

@fearthecowboy At first, I too liked how the "-" indicated "less than" and the "+" indicated "greater than," but my fear is that package authors would fall into the following trap:

  1. 1.0.0-alpha+001
  2. 1.0.0-alpha+002
  3. 1.0.0-alpha+003
  4. 1.0.0-alpha

They publish packages in that order as they work toward a their first alpha release, and discover that the actual precedence is:

  1. 1.0.0-alpha
  2. 1.0.0-alpha+001
  3. 1.0.0-alpha+002
  4. 1.0.0-alpha+003

While I can respect the desire for flexibility, I fail to see any use cases for build numbers having greater precedence than a version without them.

@Haacked "If the +007 implied a version less than 1.0.0, how would you know what version that build label labels? It's not self-contained in that case." I disagree. If 1.0.0+007 implied a version less than 1.0.0, it is implying that it's a build of 1.0.0 that is not the official release. I will reverse the question on you though, given the following scenario:

  1. 1.0.0-rc
  2. 1.0.0
  3. 1.0.0+001
  4. 1.0.0+003
  5. 1.0.0+004
  6. 1.0.0+007

What do each of those versions mean?

@fearthecowboy

My purpose for pursuing flexibility extends beyond just Nuget.

I would hope that the semver spec could find its way elsewhere too. If the spec supports both notions, then it's got increasing value elsewhere (where practice may be one side of the model, or the other -- or worse, both!)

Yes, having it support both means that surely someone will be confused at some point. I think that's really an inevitability, and you just accept that and move on.

You can't make it perfect & idiot-proof -- someone will just build a better idiot.

@Haacked
Collaborator
Haacked commented Oct 23, 2012

@jeffhandley If you're using build numbers internally, I don't see any reason to strip the build number.

I think in your scenario, you're giving the build number more semantics. You're implying it's a pre-release version of the software. I think the build number should be orthogonal.

To address your example, keep in mind that build numbers are flexible metadata so the meaning depends on who's building the package. But here's what I'd say:

  1. 1.0.0-rc // Release candidate for 1.0
  2. 1.0.0 // If you're using build numbers, this doesn't really make sense. The most sense I can make is that this is the published version of 1.0.0 RTM in a public feed which corresponds to one of the following builds of 1.0.0
  3. 1.0.0+001 // 1st build of 1.0.0 RTM.
  4. 1.0.0+003 // 3rdt build of 1.0.0 RTM.
  5. 1.0.0+004 // 4th build of 1.0.0 RTM.
  6. 1.0.0+007 // 7th build of 1.0.0 RTM.
@Haacked
Collaborator
Haacked commented Oct 23, 2012

whoops! I updated the commont to correct the annotations to each build.

@loudej
loudej commented Oct 25, 2012

My .02 would be I agree the build number shouldn't be seen as having any "public" or "release" semantics. I think it's absolutely correct to treat it as a fifth-part that only has an effect on comparison when all of the earlier four parts "x.y.z-pre" are exactly equal.

The question really comes down to if the null build number (a version with no +) is the oldest-possible or newest-possible version for a given "x.y.z-pre" coordinate.

Of course, that question is only significant if your sequence has a mix of both null and non-null build numbers.

So (a) did the person start with a null build number as the oldest, and later start using non-null build numbers to ship newer version to replace it?

Or (b) did the person start with non-null build numbers, and later ship using a null build number on the final bits?

I would say (a) is a mis-use of the final build-number component - you should really have started with a non-null build number if you're going to use it, and if you didn't you should bump the patch number once you add a build number to your system. But (b) does sounds like something that might actually be reasonable, if your nightly build is numbered but you don't want a + component in your official release.

So I'd vote for null build number being the newest-possible version, so the worst-case sequence would be:

  1. 1.0.0-rc1+5
  2. 1.0.0-rc1+6
  3. 1.0.0-rc1
  4. 1.0.0-rc2+7
  5. 1.0.0-rc2+8
  6. 1.0.0-rc2+9
  7. 1.0.0-rc2
  8. 1.0.0+10
  9. 1.0.0+11
  10. 1.0.0+12
  11. 1.0.0

But in practice more likely

  1. 1.0.0-rc1+5
  2. 1.0.0-rc1+6
  3. 1.0.0-rc2+7
  4. 1.0.0-rc2+8
  5. 1.0.0-rc2+9
  6. 1.0.0+10
  7. 1.0.0+11
  8. 1.0.0+12

or

  1. 1.0.0-rc1
  2. 1.0.0-rc2
  3. 1.0.0

but not a mix of both

@adamralph

I firmly believe the build number should be orthogonal to release/pre-release. I should be able to use it on both pre-release and release versions, not just pre-release.

The only aspect I'm still debating in my head is whether a null build number should precede or follow non-null build numbers. I agree with both Phil and Louis that mixing the two is an odd thing to do but we still need a precedence rule in place if someone does it (which someone inevitably will).

On one hand, it may better to view 1.0.0 as 'cleaner' than 1.0.0+1. That is, 1.0.0 is what I'd finally like to ship, so we make 1.0.0 > 1.0.0+1.

On the other hand, it's perhaps more intuitive if I use a plus sign that I am 'adding' to the version number. That is, a minus sign means 'less than' and a plus sign means 'greater than'. So when I change 1.0.0 to 1.0.0-rc1 then I am 'lowering' the version number. When I change 1.0.0-rc1 to 1.0.0-rc1+1, or I change 1.0.0 to 1.0.0+1 then I am 'raising' the version number.

@Haacked
Collaborator
Haacked commented Oct 25, 2012

Just throwing ideas out there, but maybe we should change the symbol to something that doesn't have the semantics of + and reflects the "orthogonality" to release/pre-release. For example, 1.0.0~build-num. Since it doesn't mean + or -, it's a stamp.

@xavierdecoster

I like Phil's idea to use something else than + or -. Using a ~ instead of a dot (or anything else) clearly separates the build stamp from the version info.

With this approach, the only convention left to decide upon is how precedence is defined. The complexity here is that - unless constrained - people will mix usage of 3 or 4 version numbers. And how is the ~ treated in relation to the 4-dots versioning scheme?

Not allowing multiple build stamps of the same version basically kills CI repositories. On the other hand, allowing this on public repositories means that people will have to deal with exotic version numbers when looking for a specific version (think about how you would use the Install-Package -Version command where auto-completion shows you a bunch of builds?). I agree that having multiple builds of the same version doesn't really make sense on a public repository, but disabling this possibility brings us back to killing CI repositories.

Reading the above insights on the meaning of the build number and its orthogonality towards the notion of (non-)release, I'm leaning towards adding more semantics to the repository instead. A repository might need a notion of "production" versus "non-production"?

I don't think SemVer should be constrained by the use-case of NuGet, so maybe NuGet could constrain repositories by how SemVer can be used by adding this notion of (non-)production?

@adamralph

@Haacked that might be a good idea. It will certainly remove any automatic mental association of 'before'/'after'. If we were to use something like ~, my vote would be to have 1.0.0~1 < 1.0.0. The rule being that major.minor.patch with any further identifiiers always precedes just major.minor.patch.

@xavierdecoster I don't think we should let .NET's 4 number versioning scheme influence us here at all. This is a problem for .NET and NuGet to work out. 4 number versioning should not be part of SemVer.

@xavierdecoster

@adamralph true, I was raising the question here with the NuGet use-case in mind. That's indeed not part of SemVer and rather something that NuGet should take care of.

I'd also vote for 1.0.0~X < 1.0.0.

@loudej
loudej commented Oct 25, 2012

~ works for me. Tried to considered briefly alternatives like 1.0.0-pre:45, 1.0.0-pre#45, 1.0.0-pre/45 but those all have some connection to foreign concept (makes the build number look like a port, anchor, or path) and would bad when uri-encoded. Ah yes, ~ is one of the very few characters that should not be uri encoded - so that works great.

+1 for 1.0.0~x < 1.0.0

1.0.0-rc15
1.0.0-rc1
6
1.0.0-rc1
1.0.07
1.0.0
8
1.0.0

@adamralph WRT nuget.exe and nuget.org those use-cases are really about the use of semver in package id, the 4-WORD scheme of windows PE file format is unrelated.

@jeffhandley
Contributor

I do like the ~ better than the + too.

Sorting precedence is still pretty controversial it seems though. Reality is, there are scenarios where BOTH situations occur, where you want the build number to be before or after the null-build-number version. I don't know how the sorting precedence can be defined to handle both situations.

@adamralph

@jeffhandley if we want to support both before and after then I guess we'd need yet another character. I can't see how ~ can mean both ;-). I suppose we could define 1.0.0~x < 1.0.0 < 1.0.0+x but I think this may be getting a bit too complex.

WRT to NuGet and 4 word versioning, am I right in understanding that a 4 word version is not a valid semver version? If so, and if NuGet wants to follow semver, then NuGet should disallow 4 word versions. If semver achieves its goal as a universal versioning scheme then there should be no issue in having NuGet follow it to the letter. Obviously NuGet would need a strategy for dealing with existing packages with invalid semver versions.

@jeffhandley
Contributor

Yes, NuGet supports both SemVer and 4-word versions. SemVer support was new with NuGet 1.6, so we have to support the classic versions for backwards compatibility. We don't intend to drop support for that, but we do promote SemVer for packages.

And yes, 4-word versions should not be part of SemVer.

Back to before/after: I have been thinking more about how I see software get built and released, especially when CI builds are in the picture.

  1. The CI server just keeps on building stuff, perhaps multiple builds per day, stamping each build with a build number
  2. The team tests the builds that get pumped out of the CI machine
  3. The team finds a bug that is a potential ship-stopper
  4. A fix is made and the CI server pumps out a new build
  5. The team tests this new build and finds that it's worse than the previous build.
  6. A decision is made to ship the previous build as the official release, with a known issue
  7. A new release branch is created, the version number is incremented, and life goes on
  8. Meanwhile, the branch for the now-released version still has a CI server running against it, for servicing reasons (ensuring that you can still build the old version of the software in case you need to patch it). The CI server is now producing builds with a build number greater than the released software

We end up with a stream of build numbers and somewhere in the middle of that stream, a specific build was selected and made an official release. When a build is being produced, it cannot know which it will be:

  1. Before the official release
  2. The official release
  3. After the official release

That decision hasn't yet been made when the build is produced, so there's no way for the version number to indicate it. That means it is impossible to define the precedence between versions that have a build number and versions that don't.

@adamralph

@jeffhandley you make a very good point, which again demonstrates that a product should either be versioned with build numbers or versioned without build numbers but a mix of the two practices serves no purpose. What that implies is that precedence is of no importance. I guess precedence still needs to be defined because ultimately 1.0.0~x has to be defined as being either greater than or less than 1.0.0 but which way round is chosen makes no difference and we may as well flip a coin. Anyone have a coin? ;-)

@jeffhandley
Contributor

If we are just going to flip a coin, then perhaps the spec should just say that no relationship can be defined or inferred between versions with and without build numbers.

Sent from my Windows Phone


From: adamralph
Sent: 10/25/2012 1:52 PM
To: mojombo/semver
Cc: Jeff Handley
Subject: Re: [semver] Build Number Precedence is Backwards (#51)

@jeffhandleyhttps://github.com/jeffhandley you make a very good point, which again demonstrates that a product should either be versioned with build numbers or versioned without build numbers but a mix of the two practices serves no purpose. What that implies is that precedence is of no importance. I guess precedence still needs to be defined because ultimately 1.0.0-x has to be defined as being either greater than or less than 1.0.0 but which way round is chosen makes no difference and we may as well flip a coin.

Reply to this email directly or view it on GitHubhttps://github.com/mojombo/semver/issues/51#issuecomment-9793624.

@jeffhandley
Contributor

I was just chatting with @nikhilk about this and he made an interesting point. "While one might opt into build numbers mid-stream, it's unlikely one would opt out of build numbers after adopting them. Therefore, it's logical that build numbers should have a higher precedence than null build numbers." That's a pretty good argument. Maybe not a firm enough argument to dictate which side of the coin we should call though.

@loudej
loudej commented Oct 26, 2012

I'd still assert the null build number should have higher precedence for packagers that want a clean version 1.0.0 when officially published, but also want 1.0.0+x nightly or checkin builds.

I don't buy idea about designing the ordering to accommodate a shift in practices. You can easily add build number when you bump the patch number if you're opting in for the first time. Or delist the pkg with no build #.

But outside of the one-time shift in explaining practices, I think the natural expectation of someone who intentionally & repeatedly exposing both 1.0.0 and 1.0.0~x is that the 1.0.0 is the sticky, golden copy.

@loudej
loudej commented Oct 26, 2012

*One-time-shift in your packaging practices

Dang autocorrect

@jeffhandley
Contributor

Where I believe we left off is that the only remaining issue is whether "2.0.0" is newer or older than "2.0.0+1." Unfortunately, it seems like we're split on this, which means we'll just need to make a decision and move on. I'd really like to get past this though and get this spec to RTM state so that NuGet can work to add support for build numbers.

As I've thought more about this the last several weeks, I can accept "2.0.0+1" being newer than "2.0.0." While I think it will cause confusion as package authors start adopting build numbers in their versions, I can imagine a world where there's no such thing as an "RTM" version, but where it's simply understood that the newest build of a version is the best one. It might just be a case of "things must get worse before they can get better."

@loudej
loudej commented Dec 14, 2012

I have to say id still vote on 2.0.0 being newer than 2.0.0+1, if for no other reason than it follows the same rules as pre tag. But I agree it's good to close one way or the other.

@adamralph

(I'm going to use ~ instead of + since I that was what we were leaning towards previously.)

I think this was already suggested above, but after some more thought, I'm in favour of SemVer defining no precedence for the the ~ denoted part. That is, 2.0.0 is the same semantic version as 2.0.0~x and ~ denotes metadata that does not form part of the semantic version.

When it comes to listing a series of versions in a UI, some which may have a ~ part and some without, I believe that the order of 2.0.0 and 2.0.0~x is irrelevant and can ultimately be decided by the UI component performing the listing.

What this would mean for NuGet is that a package author can only push 2.0.0 or 2.0.0~x once regardless of whether further builds have taken place with differing ~ parts. This also means NuGet doesn't even have to consider how to order versions w.r.t ~ parts.

@Haacked
Collaborator
Haacked commented Dec 14, 2012

I think '~' not defining a precedence could work as long as package managers don't mix packages with build metadata with packages that don't have build metadata.

Thinking about it more, that actually makes a lot of sense to me if you don't consider a version with ~ metadata to be a new semantic version. It's the same version of the package, but with metadata.

For example, in a public package repository, suppose a package has the following versions:

  • 1.0.0
  • 1.0.0~20121214

Both of these would not be allowed to exist in the repository because they are the same semantic version of the package.

Of course, some shops may want to have a private repository that has daily builds that would allow multiple packages of the same version. That's sort of their perogative and they can define the precedence rules that fits them. Package hosting software might allow a "private feed" mode to support this.

I think this elegantly solves the problem of not being able to define a precedence for build metadata that works for everyone. Just don't and make sure it doesn't impact sharing of published packages.

@fearthecowboy

So, you're saying that only the #.#.# is of any value when determining precedence?

That seems like an incredibly limited amount of version information; how exactly are we supposed to map well-established, existing library version with greater fidelity if three numbers is all you get.

For example, OpenSSL has versions: 1.0.0a 1.0.0b 1.0.0c 1.0.0d ...

If we can support those as :

1.0.0+a < 1.0.0+b < 1.0.0+c

then I have no problem.

I personally liked - and + indicating which side of the #.#.# that represented. It allows existing version data to be accommodated without losing fidelity, and it supports the two trains of thought on how people like to think of their product version (I don't use 1.2.3-pre1 -pre2 -pre3, but I understand those who do).

I'm currently at the center of a project to bring a unified pluggable packaging/installation API into Windows (which will ship in-box in the future, and OOB for downlevel) and I can tell you if semver doesn't support the flexibility that we already see in the real world, it's not likely going to be used in the API.

@Haacked
Collaborator
Haacked commented Dec 14, 2012

Well that and the pre-release tag. So #.#.#-prerelease would only be used to determine precedence.

@Haacked
Collaborator
Haacked commented Dec 14, 2012

@fearthecowboy are those all non-prerelease versions?

@fearthecowboy

No, in OpenSSL's case, those are all post-release versions.

1.0.0. < 1.0.0a < 1.0.0b < 1.0.0c

They aren't alone in this either. There are two distinct trains of thought:

  • those who like to lead up to a version (1.0.0-pre1 .. -1.0.0beta1 ... 1.0.0-rc1 , etc) and finish with a 1.0.0.
  • those who like to append significance after the version. (like OpenSSL)

Both models should be supported.

I'd rather not pass judgement upon those who are obviously wrong and use the model that I don't ... I think that their heathen ways should be permitted regardless of how wrong they are :D

@loudej
loudej commented Dec 14, 2012

I agree with Phil's observation. In the package management case the treatment of that boundary condition in build number could very will be just implementation detail in the repo and client. That might be best - if it's undefined by the semver spec it may be that best precedence would vary by use case.

In other words - pinning it down now could do more harm than good? If we find in practice that there is a with-without sort that does work best in all cases - then that can be added to semver in a patch?

@loudej
loudej commented Dec 14, 2012

@fearthecowboy wouldn't the openssl example be more of a case for alphanumeric major.minor.patch values? That is, patch "0" < patch "0a". Heathens, clearly, but not quite the same as a post -prerelease values.

@Haacked
Collaborator
Haacked commented Dec 14, 2012

@fearthecowboy heh heh. Well, SemVer isn't meant to match all possible versioning schemes. It's meant to provide a scheme that provides concrete semantics to each version.

If those are post-release versions, then I would suggest they map the following in SemVer:

  • 1.0.0 -> 1.0.0
  • 1.0.0a -> 1.0.1
  • 1.0.0b -> 1.0.2
  • 1.0.0c -> 1.0.3

I'm assuming that those are all backwards compatible updates with no new features and just bug fixes. They feel like Patch updates to me per the current existing SemVer spec.

The discussion we're having here is not to change the meaning of the existing SemVer version parts, but to allow for adding metadata to a version that doesn't affect the versioning.

Note that applying a build tag does allow appending significance after the version. It just wouldn't allow you to have more than one at a time.

So under the current proposal,

1.0.0~buildmetadata implies this is really the release 1.0.0 but with some build metadata attached. What it doesn't imply is that

1.0.0~buildmetadata > 1.0.0. It doesn't imply anything. They're the same version as far as SemVer is concerned.

@Haacked
Collaborator
Haacked commented Dec 14, 2012

I should clarify. It wouldn't allow you to have more than one package with the same version, but different build tag, released at the same time. By released I mean shared in some public repository. Because from a SemVer perspective, they're the same version.

But for an internal build server, you can apply your own additional semantics to the build tag if you want. After all, it's your build server. The idea being you're working towards some release that's going to comply with SemVer.

@fearthecowboy

That mapping isn't going to work!

OpenSSL has fidelity in their versioning where

1.0.0 < 1.0.0a < 1.0.0b ... (all binary compatible)
1.0.2 < 1.0.2a < 1.0.2b ... (all binary compatible)

and 1.0.0* not binary compatible with 1.0.2*

I understand that ~ indicates additional metadata that doesn't imply precedence -- my concern is that 1.0.0b is a binary upgrade from 1.0.0a, and both are perfectly valid in a public repository at the same time.

I can't start renumbering their versions (that would create nothing but confusion) and I can't simply replace 1.0.0a with 1.0.0b (there may indeed be a reason that someone wouldn't want 1.0.0b, but would rather stick with 1.0.0a)

@loudej -> OpenSSL is an example of one of many projects, and each one often has a slightly different take on what their version numbers mean.

I'm just not sure what the actual resistance to supporting both '+' and '-' (and, hey whynot '~') is...

@Haacked
Collaborator
Haacked commented Dec 14, 2012

@fearthecowboy as I understand it, if 1.0.0* is not binary compatible with 1.0.2* then OpenSSL's versioning does not conform to SemVer as of today. Are you suggesting we change SemVer to conform to OpenSSL?

@ericschultz

I guess I'm confused as to what the issue is. '+' and '-' seem to actually be a pretty logical way to handling when versions are above or below the standard version numbers. What is the necessity of changing the order of precedence? I don't get why there's a need to change build-order precedence.

As for OpenSSL not conforming, that's fine. If we want them to have a place in a packaging system that is based on SemVer though, we can't make them have a different version internally while having a totally different one for packaging unless we have an amazing reason. It's too confusing to end users.

@fearthecowboy

All I'm asking for flexibility.

I can't change the universe, and how individuals imply their compatibility policy into their version numbers isn't all that important to me.

If OpenSSL's compatibility policy scheme doesn't map with SemVer's intended policy model, then I'd recommend that you not try too hard to dictate compatibility policy in a versioning scheme, and allow flexibly versioning with a suggested model for how to determine compatibility.

@virmitio

@Haacked Are you suggesting that an arbitrary piece of software must rewrite their entire version history in order to be accepted into a repo using SemVer due to their versioning scheme to date not having the same compatibility policy meaning?

If so, does that also mean that no attempt could be made to include such a piece of software in a repo using SemVer until the software has replaced its established versioning scheme?

Edit: I realize after reading this post that it may sound like an attack, but I honestly just need clarification.

@serialseb

@Haacked brought me to this thread so I'll jump in.

You need to separate two things: the version you declare in your pacakge, and the dependency you can take. in OpenWrap we don't allow you to take dependnecy on the + part (and as we've already implemented semver2 when it was published, and as it was an RC, I'd rather + stayed instead of tilde. Not a big deal but that makes our deployments now have invalid semver packages for the sake of looking nicer, ouch).

I don't care much on the precedence issue, except for the fact that it's going to change the semantics of existing packages. OpenWrap auto-converts windows versions to semver versions. The issue here is that users expect 1.0.0 < 1.0.0.1 in the wild, in the gazillion of packages already out there we use. Implementing the reverse means breaking authors prior expectations. Implementing two code paths depending on what the version number means (aka make it significant for windows versions and non-significant for semver) would be difficult and messy to implement, go against the expectations the majority of windows users have, break existing packages and existing implementations of semver RC. So personally I'd simply leave the precendence the way it is, and add a note about not taking dependencies that depend on build numbers. This leaves the spec clean without screwing with the existing world of packages out there (which I've already discussed in #6).

In other words, I vote for not changing anything and privileging compatibility over logical purity. Those that implement semver correctly would probably not have build numbers without having a -pre and remove the -pre and the +build when releasing, and the current spec supports that, while still supporting the existing scenarios that were covered.

@ericschultz

The way to move this forward is for those proposing the change to explain the best way to fit something with a non-SemVer versioning system, like OpenSSL, into a SemVer packaging system. Is there a proposal on how to go about doing that?

@Haacked
Collaborator
Haacked commented Dec 14, 2012

@virmitio it's really up to each repo to decide whether they accept non-SemVer packages. The point here is that Major.Minor.Patch for SemVer is already defined in SemVer 1.0 RTM. This PR is not an attempt to redefine those things. If you read the SemVer spec, you'll see it says that you increment Patch for backwards compatible bug fixes. I take that to imply binary compatibility.

So if you have a package 1.0.0 and follow it with 1.0.1 which is not backwards compatible with 1.0.0, you're not complying with SemVer. Which is fine. SemVer isn't some god given mandate. It's a versioning scheme that applies semantics to each version part.

In cases where existing libraries have a different versioning scheme, but want to be included in a SemVer compliant package repository, they can use a SemVer package version while keeping their library version whatever they want. We can distinguish package versions from the version that's marketed to the public.

The benefit of SemVer is that given a package version, you can reason about the version. Package managers can apply "safe" updates where they only update all Patch versions for example.

If we try to fit into every possible versioning scheme, then SemVer has no semantics.

@serialseb so if I understand you correctly, in a released OpenWrap feed, you would not allow two versions with different build numbers. Correct?

Aka, 1.0.0+1 could not coexist with 1.0.0+2. Or are you saying they could, but you cannot take a dependency on a specific build .You'll always get the latest one?

@Haacked
Collaborator
Haacked commented Dec 14, 2012

BTW, I'm fine with + or ~. The symbol isn't as important as getting the semantics correct. And as @serialseb pointed out, SemVer 2 is an RC spec so changing the symbol willy nilly is probably not a good idea. So I propose we keep it + but make sure we nail the semantics.

@serialseb

No we allow of course 1.0.0+1 and 1.0.0+2 and +2 takes precedence but you can't take a dependency on >= 1.0.0+1 for example.

The point is that we don't have an openwrap feed any differently than we have the nuget feeds, they're all the same and work the same way. You take a dependency on 1.0.0 and that's that. (it's not entirely true, we have exact matching operators for those cases where the package author made a mistake and you're screwed by the package versioning, because the real world, and as such the nuget feed, is full of those mistakes).

Say waht you must but no spec should be built that forgets about all those existing packages, even if it hurts the "purity" of the spec a bit. :)

@fearthecowboy

The RC Spec was fine for me, I was happy for that.

I'm just saying that the content after + has to be considered to be more than simply cosmetic, and it's as important as being able to specify - in the version.

As long as I can practically map version semantics from projects like OpenSSL into SemVer without losing fidelity, I'm ok.

@ericschultz

I'd like to point out that literally everyone in this conversation is involved in the .NET or Microsoft world. SemVer isn't just for us so where are the non-.NET people? We need to know what they think before we start breaking possible scenarios. Maybe they have thoughts on what's best?

@jeffhandley
Contributor

Here's an idea...

  1. Keep the spec as-is with regard to the + symbol and the ordering of build numbers themselves
  2. Allow multiple build numbers of a version to coexist
  3. State that there NO precedence can be determined between a version without a build number and a version with a build number, and therefore they cannot coexist. That means 2.0.0 and 2.0.0+2012121401 are not allowed to be present on the same feed.
  4. Recommend that feeds can support "virtual versions" where in the above case 2.0.0 would resolve to the newest build of 2.0.0. That way, a "recommended build" can be specified and served for any version.

It really seems like the biggest hangup is the precedence between no build number and build number, where the rest of the version is the same. We can just avoid that by saying they cannot coexist.

@Haacked
Collaborator
Haacked commented Dec 14, 2012

@ericschultz I asked one of the ruby gem folks to chime in if they care.

@jeffhandley heh. Back to the beginning. But I think you nailed the real issue. How does:

2.0.0 compare to 2.0.0+1?

If we say there is no comparison, then we kind of solve that problem, while retaining that 2.0.0+1 < 2.0.0+2.

This would allow for OpenSSL to map 1.0.0a to SemVer's 1.0.0+a.

@fearthecowboy @serialseb thoughts?

@qrush
qrush commented Dec 14, 2012

I really think this is all out of scope for SemVer. SemVer is about released open source code and keeping promises to consumers of that code. If it's a prerelease, I don't see any reason why such a complicated system needs to be put into place.

@fearthecowboy

I can't see why 2.0.0 can't compare to 2.0.0+1

OpenSSL does publish 1.0.0 and 1.0.0a (which to me would be 1.0.0 and 1.0.0+a )

Actually, they also use the - model too. Published versions of OpenSSL, showing highest version is at the top:

openssl-1.0.0c -> 1.0.0+c
openssl-1.0.0b -> 1.0.0+b
openssl-1.0.0a -> 1.0.0+a
openssl-1.0.0 -> 1.0.0
openssl-1.0.0-beta3 -> 1.0.0-beta3
openssl-1.0.0-beta2 -> 1.0.0-beta2
openssl-1.0.0-beta1 -> 1.0.0-beta1

@serialseb

Hum. No comparison doesn't fly. It's an undefined in a spec and a recipe for nightmares. The current solution, while less pure (and if I was going for purity I'd support lou's points) allows for both people doing semver right and the ones not doing it to sill work. Changing it in the proposed way respects the spirits but breaks existing feeds, my implementation of semver and user expectations.

Don't get me wrong, it's not the end of the world, the dependency resolver in OpenWrap supports multiple resolution strategies so I can work around the problem, but the current spec is the smoothest, with the least implementation hurdles and gives the most expected results for package developers.

On 14 Dec 2012, at 18:14, "Phil Haack" <notifications@github.commailto:notifications@github.com> wrote:

@ericschultzhttps://github.com/ericschultz I asked one of the ruby gem folks to chime in if they care.

@jeffhandleyhttps://github.com/jeffhandley heh. Back to the beginning. But I think you nailed the real issue. How does:

2.0.0 compare to 2.0.0+1?

If we say there is no comparison, then we kind of solve that problem, while retaining that 2.0.0+1 < 2.0.0+2.

This would allow for OpenSSL to map 1.0.0a to SemVer's 1.0.0+a.

@fearthecowboyhttps://github.com/fearthecowboy @serialsebhttps://github.com/serialseb thoughts?


Reply to this email directly or view it on GitHubhttps://github.com/mojombo/semver/issues/51#issuecomment-11387124.

@Haacked
Collaborator
Haacked commented Dec 20, 2012

Ok, at this point I'm inclined not to change anything. As @serialseb points out, this is an RC spec. If we had overwhelmingly strong agreement to change it, I would.

Going back to the original issue, @jeffhandley was concerned about builds marching towards a pre-release version. I think this can still be accomplished with the current plan.

If you use build numbers to "march towards" a release, then you simply need to ship a package that has a build number. The one corresponding to that release. For example:

  • 1.0.1-alpha+0001
  • 1.0.1-alpha+0002
  • 1.0.1-alpha+0003 <-- THIS IS THE ONE! :shipit:
  • 1.0.1-beta+0001

Note that this doesn't imply that any given package manager has to surface that build information. In fact, it probably doesn't make sense to show the build number prominently anywhere. For example, don't allow taking a dependency on a specific build of a package. Treat the build number as metadata for the version.

However, I do think it's fine for SemVer to add this to the spec simply to allow people to have build processes generate packages and not have SemVer flag them as invalid. That way you don't have to strips everything after (and including) the + sign when you publish the package.

@loudej
loudej commented Dec 20, 2012

Although I agree with your analysis I don't really agree with the conclusion about doing nothing.

We have lots of packages published to myget from a 'dev' nightly branch, like 1.0.1+42 and counting, that will ultimately be published from a 'release' branch from a different teamcity project configuration. Even if the TC 'release' config added build number to the package id they wouldn't be from the same counter. Know what I mean?

I guess you could hack it by adding a thousand to the release TC config build number, but IMO it would be the most elegant if 'null' build number meant, semantically, 'final' build number.

It's not the end of the world, of course, but it does make the build number viral (if you want it in nightly you MUST use it in official) when it doesn't need to be that way if it followed the same rule as -pre.

@adamralph

@loudej wouldn't your nightly build be 1.0.1-nightly+x and your release build 1.0.1+y?

@loudej
loudej commented Dec 20, 2012

Nope, nightly would be producting the same as the next milestone drop.

If the next drop will be 1.0.1-rc1 the nightly will be 1.0.1-rc1+42 and counting. Once 1.0.1-rc1 is published the nightly shifts to 1.0.1-rc2+n. Then when 1.0.1-rc2 ships the nightly starts producing 1.0.1+n. Then 1.0.1 is published.

And yeah, you always may publish the officials with the +n intact. Point is if missing build number sorted as first - then you MUST publish with +n intact. But if missing build number sorted as last then you can publish with or without the + and be okay.

I'd really like to use +n on the nightly builds, which is why I have an opinion, but I'm afraid we won't be able to if it also means we MUST ship the official packages with a +n on the ver to ensure precedence.

@Haacked
Collaborator
Haacked commented Dec 20, 2012

@loudej what is your objection to shipping +n for the official package?

@loudej
loudej commented Dec 20, 2012

For nuget specifically, even if it is hidden by tooling and gallery, it will appear in the ./packages/name-ver/ folder and hint paths.

Plus the TC server config producing nightly&triggered build on myget is not the same as the one producing release build on a secure UNC file share. In that case it's not as simple as taking the last publicly visible nightly and popping it onto nuget - the official build +n is hundreds out of sync with the nightly build +n.

What I don't understand... What is the problem with having 1.0.1 take precedence over 1.0.1+n? The only thing you lose: you can't upgrade from 1.0.1 to 1.0.1+n. IMO that's fine because the goal of +n is not to add semantics for a sub-patch version number.

Plus there is a very simple fix for "I didn't use +n before, and now I do, and the previous build is covering up the new one." That problem goes away automatically the next time the patch is increased. It's extremely momentary, arguably a non-issue.

It's a billion times less impactful to say "one time: to use +n on an existing package you MUST increment at least one other part" than to say "from now on: to use +n you MUST ship official package including the best +n and SHOULD NOT expose +(n+1) on nightly feeds to avoid having 1.0.1+43 on a nightly feed look like an upgrade to the 1.0.1+42 on the official feed"

@Haacked
Collaborator
Haacked commented Dec 20, 2012

@loudej I think @fearthecowboy had the strongest objection to that if you scroll above. It was in reference to OpenSSL versioning.

So this is the big question.

Should

1.0.0+1 < 1.0.0

or

1.0.0 < 1.0.0+1

As an aside, although a bit inelegant, couldn't you do your scheme by always using a "_nightly" pre-release prefix? You'd simply remove the "_nightly" when you're ready to cut a release.

  • 1.0.0-_nightly.rc1+001
  • 1.0.0-_nightly.rc1+002
  • 1.0.0-rc1
@loudej
loudej commented Dec 20, 2012

Yes, I recall that, and the OpenSSL example is irrelevant to the question of build number semantics. They are not indicating their build server has incremented from 'null' to 'a'. OpenSSL is saying 1.0.0 < 1.0.0a, which means they are using an alphanumeric patch field.

And yes, there are any number of work-arounds for the fact the semver build number sort would be broken. :) They all boil down to "hack the -pre value" which is the solution we are stuck with today.

@loudej
loudej commented Dec 23, 2012

Rewinding all the way to the top, rereading the original issue description for perspective it does say "I guess I’m just not sure why you’d need to have additional builds after a version. Once a version is released, it’s done; new builds should be a new version. If there was something wrong with the version that was released and you need to put out a new build, then it’s a Patch to the broken version and therefore the patch number should be increased."

I agree with that, and the remark "discussion participants unanimously agree that build numbers march toward a prerelease version." Note also every example cited shows build numbers marching toward a prerelease, or release, which does not have a build number attached.

All of that says to me 1.0.0-rc1+41 < 1.0.0-rc1 < 1.0.0+42 < 1.0.0 < 1.0.1+43

@ferventcoder

Ha, just noticed this thread. I have to say I agree with Nick ( @qrush ) - why complicate a spec that should be simple to understand and follow? SemVer 1.0 RTM is simple, easy to understand and it doesn't try too hard.

As an artist (read: painter, sculptor, etc) there is a line of knowing when something is done.

What is being proposed for 2.0 will open SemVer to quite a bit of abuse and misinterpretation, as evidenced in this thread by all of us that already have a good understanding of versioning.

Reading through the proposed spec only brings one thing to mind:

  • Having a need to attach a build number to the end of a release should just be a new patch for the version.

Let me explain: 1.0.0+1 should really just be 1.0.1 - otherwise it gets abused and misused because it is no longer simple to understand.

My good friend @mhinze once said "Simple ain't easy." If it were up to me, I would eradicate Number 10 from the proposed spec changes. It's not up to me though.

For reference, this is Number 10 that I'm referring to:

  • "A build version MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch version or pre-release version. Identifiers MUST be comprised of only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Build versions satisfy and have a higher precedence than the associated normal version. Examples: 1.0.0+build.1, 1.3.7+build.11.e0f985a."

My only advice in this space is Keep It Super Simple.

@ferventcoder

Also, having the prerelease version numbers in the spec allows me to get my version metadata s--t together. So if I haven't fixed it by the time I release a major/minor version, then that's my fault. It's not because I misinterpreted a spec.

@Haacked
Collaborator
Haacked commented Jan 7, 2013

@ferventcoder It's only complicated because we haven't yet agreed on what it means. I definitely value simplicity. However, I think you can go too far the other way. Too simple so that you don't solve real problems. I think there's a real challenge here.

People need build information in their package versions. Incrementing patch version isn't sufficient. For example, if I compile twice, but nothing has changed, then incrementing the patch version number is actually wrong. It's communicating to the consumer that something has changed when nothing has.

The way I think of it is that the SemVer version part communicates to the consumer. But the build number communicates to the creator. It's meant to be private.

I'd be happy with saying, "everything after the +" is ignored for the purposes of SemVer. That way you can put whatever you want in there and if you deploy it with a build designation, SemVer doesn't flag it as invalid, but it also doesn't do anything with the part after the "+". In that way, it's more like a SemVer version comment than part of the version.

@loudej want to send a PR with your proposed changes to the spec?

@ferventcoder

@haacked I get the build twice. But what I don't get is why there would be two of the same VERSIONs (edited from builds) packaged up. Why would I need the second one?

@ferventcoder

I'd argue against build number over the long term.

  • What happens when I switch my build server to a new location?
  • What happens when I switch build technologies (Jenkins to TeamCity or vice versa)?
  • What if I am using more than one build server in tandem?
@ferventcoder

Now, if you buy into that for a period of time I would have

  • one build server as the central build source
  • used only for my information (private as @haacked mentioned)

then this starts to make more sense. But to me it kind of pollutes a spec which can be universally applied (in present form).

Again, it's not really my decision in this. Someone believes this is necessary and real world. Which is fine, I just wouldn't add it.

@ferventcoder

@haacked:

The way I think of it is that the SemVer version part communicates to the consumer. But the build number communicates to the creator. It's meant to be private.

I agree with this statement. SemVer is separate from build number. ;) Which makes me think that perhaps build number goes with NuGet and not with SemVer.

@serialseb

A build number is exactly like appending a number segment to a -pre. I don't want to change the version I chose for my next version between two CI builds. I could have -pre.1 or +1-pre and they mean the same thing. Just the same, the ordering between -pre.1 and -pre should be the same as with +1 and not having a build.

They're semantically equivalent and solve the same problem in my view, but give the choice to the producer of a package. All the same I still support ignoring build numbers and -pre segments when defining version ranges (on the consumer side), but the specification does not make a difference between those two sides.

Other scenario why a build number is useful is for changes that are mechanical in nature. I change the zip compression level on my server, or the previous file was corrupted when uploading.

In both of those scenarios, changes are I starters with 2.0.0 and having 2.0.0 < 2.0.0+0 means I do have an exit scenario for reuploading the same package. Changing the spec also break that scenario. Keeping the same file name is not an option for any system that uses http caching.

As 2.0.0 takes precedence over any -pre, relying solely on that doesn't solve the problem. Changing the spec removes options for package producers, is counter-intuitive for those systems that use 4 numbers for version, and provide no benefits whatsoever versus the already implemented rc spec.

I've not seen anything to convince me that the amount of work put in this discussion is worth it beyond design by committee. But then again I don't like when DbC goes against implementation experience, and we've not had any issues with the implementation and deployment of openwrap-based solutions that use the RC spec as-is.

On 7 Jan 2013, at 19:52, Rob Reynolds <notifications@github.commailto:notifications@github.com>
wrote:

I'd argue against build number over the long term.

  • What happens when I switch my build server to a new location?
  • What happens when I switch build technologies (Jenkins to TeamCity or vice versa)?
  • What if I am using more than one build server in tandem?


Reply to this email directly or view it on GitHubhttps://github.com/mojombo/semver/issues/51#issuecomment-11968236.

@ferventcoder

@serialseb

A build number is exactly like appending a number segment to a -pre. I don't want to change the version I chose for my next version between two CI builds. I could have -pre.1 or +1-pre and they mean the same thing. Just the same, the ordering between -pre.1 and -pre should be the same as with +1 and not having a build.

How often do you force a build so that it builds the same version?

Other scenario why a build number is useful is for changes that are mechanical in nature. I change the zip compression level on my server, or the previous file was corrupted when uploading.

Real world scenario, how often does this happen?

I still think that these things are so few and far between that I see no reason for it. To be honest in my implementation experience, mistakes I made happened more when I was learning the system (ruby and .net) versus working with existing packages that I had been maintaining. In the beginning I would have jumped on the chance for being able to fix something with the package, but over time and experience to me I believe it is really a new version.

Of course I think we are all saying the same thing about new version, it's just the technical details to me of what that means.

@ferventcoder

@haacked My arguments here were also to keep down on misuse and abuse.

Say we put this system in place. and then we put it in place on NuGet. I saw mentioned that this build information may be invisible, but I don't yet technically understand what that means. My question is now, does that mean that nuget would only display the most recent build of that version and pretend that they are all exactly the same?

I'm going to make the assumption for the moment that that IS the case. And for that I think would be a very bad thing.

Scenario

Let's say we have a package for interacting with Disqus.

I'm a user and I need that package. The maintainer has uploaded 1.0.0+build1. On NuGet this is invisible to me (right? or am I wrong here). I see only 1.0.0. So I set up package restore and the world is hunky dory.

Fast forward a few weeks. The maintainer realizes something is wrong. One of the disqus fields (not one of the visible ones though) was not getting set from the code. He fixes it, and he determines that this was really just a mistake and not a public api change and uploads 1.0.0+build2. The problem is the maintainer should have incremented the patch, not the build number.

So now the build1 doesn't catch a small field, but build2 does. But that is invisible to users of NuGet. They only see 1.0.0.

Now using package restore a new developer comes onto the project.

  • Which of those two packages does he get?
  • Why does it work when he runs it and no one else?

Visible?

So I'm hoping no matter what, this information makes it out to the clients and is NOT invisible.

@serialseb

I am not disussing removing builds, that's another conversation which i wouldn't care about much. It would simply means that there ought to be another conversation (the same as this one) for package managers dealing with the fourth component of a version for those environments where there are 4. The advantage of the existing spec is that it is compatible with the approach existing packages have, with the existing deployments of openwrap and with our implementation of semver, as is.

As for real scenarios, it happens. A lot. Locally. So locally I may build the package quite a few times because I made a mistake, because in our toolchain packages are built as part of the normal development process (as opposed to NuGet where the toolchain pushes you towards building packages at deploy time). So having twenty builds of the same code happens all the time. As we automate version generation too, that's done by the tool chain not by someone doing a package.

So for me it's an absolute no-brainer. Enforcing no build number means I now have to delete the file before rebuilding, or overwrite (and there will probably be a lock somewhere, in fact it happens so often at dev time that we went for build numbers auto-increasing exactly for that reason).

If you remove the build number my development methodology and process, which gets me building hundreds of packages every day, becomes much much more complicated.

And again, for us the existing spec work. Removing the build number does not. And reordering things in the way proposed brings nothing to the table and removes some of our core scenarios.

That this conversation is running that long with such theoretical concerns is concerning beyond belief and reminds me way too much of other efforts that got fucked up for months and years by white coats. There was a spec, it was RC, it was implemented, it works, why are we still discussing this?

If the spec change we won't call what we do in OpenWrap semver (or "we were semver-based for a year but then nuget wanted to adopt semver so semver changed after its RC2 and so now we're not compatible anymore"), if it does we'll call it OpenWrap versioning and automatically replace any a.b.c by a.b.c.0 when opening nuget packages, and all will be fine in the world and no problem will really exist and I'll continue being happy. And if build gets removed then we'll put it back for our packages (and the nuget packages out there that we consume natively) and we'll still be happy.

So I'm out of this conversation, I care not for what semver becomes. We implemented RC2 and we're staying on that for the foreseeable future, you're free to do the same and @mojombo is free to do what he wants with his spec. Enough keystrokes wasted on such minute issue.

Seb

On 7 Jan 2013, at 20:24, Rob Reynolds <notifications@github.commailto:notifications@github.com>
wrote:

@serialsebhttps://github.com/serialseb

A build number is exactly like appending a number segment to a -pre. I don't want to change the version I chose for my next version between two CI builds. I could have -pre.1 or +1-pre and they mean the same thing. Just the same, the ordering between -pre.1 and -pre should be the same as with +1 and not having a build.

How often do you force a build so that it builds the same version?

Other scenario why a build number is useful is for changes that are mechanical in nature. I change the zip compression level on my server, or the previous file was corrupted when uploading.

Real world scenario, how often does this happen?

I still think that these things are so few and far between that I see no reason for it. To be honest in my implementation experience, mistakes I made happened more when I was learning the system (ruby and .net) versus working with existing packages that I had been maintaining. In the beginning I would have jumped on the chance for being able to fix something with the package, but over time and experience to me I believe it is really a new version.

Of course I think we are all saying the same thing about new version, it's just the technical details to me of what that means.


Reply to this email directly or view it on GitHubhttps://github.com/mojombo/semver/issues/51#issuecomment-11969702.

@loudej
loudej commented Jan 7, 2013

@Haacked sent a PR as #61

I've tried to make the dispute a non-issue by stating explicitly where build number is appropriate. That is to say - it is not a substitute when you would increment the patch today. The build number is only a build number - not an additional field for "oops" releases - that is what patch has been for and that should not change.

Unique build versions MAY be denoted by appending a plus and a series of
dot separated identifiers immediately following the patch or pre-release version.
Identifiers MUST be comprised of only ASCII alphanumerics and hyphen [0-9A-Za-z-].
Unique build versions satisfy but have a lower precedence than the associated
normal or pre-release version. Examples: 1.0.0+build.1, 1.3.7-alpha.1+build.11.e0f985a.

Unique build versions MAY be used to declare a reference within an otherwise
ambiguous sequence, as exists in the artifacts produced by a build server, but
MUST NOT be used to indicate an upgrade when incrementing the patch or pre-release
version is semantically appropriate.

That seems in line with the rest of the spec, which has line-items to explicitly state the cases where minor and patch are used appropriately.

@Haacked
Collaborator
Haacked commented Jan 8, 2013

Closing this in lieu of the PR.

@Haacked Haacked closed this Jan 8, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment