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