Extend schema to support incremental builds

[thompson-tomo]

NuGet Product(s) Involved

Other/NA

The Elevator Pitch

Improve support for incremental releases by introducing new attribute IncrementalBuild to simplify the lives of developers by enabling incremental builds to be hosted on nuget.org alongside other builds which will eliminate the need for additional nuget sources. This also helps with package source mapping.

Additional Context and Details

Nuspec should introduce a new attribute IncrementalBuild with a default value of false to signify that this version when used in conjunction with a preview version is an incremental build hence can be very unstable.

Incremental builds should be indicated on nuget.org in a similar manner to deprecated packages.

Nuget.org should limit the number of incremental builds hosted based on the major + minor version as well as age. Currently this process is overcome by relying on additional nuget feeds which doesn't play nicely with package source mapping.

[donnie-msft]

Could you explain more about why this should be handled by a package feed?
Would this also need to be supported on feeds other than nuget.org?

Is the package version changing each time in this incremental build?

What is the issue you're seeing with package source mapping and multiple feeds? Have you tried creating multiple package source mappings for the same package id/pattern to the different feeds? There's no limit or one-to-one restriction on that.

[thompson-tomo]

A while ago, i was having issues with mapping multiple sources but it has been a while so might be different now. Yes the package version suffixx is incrementing each build however currently it is difficult to ensure builds are running the latest version hence leading to updating issues. A scenario would be: * incremental builds prefixed with "-ci" + a build number * Alpha builds prefixed with "-alpha" + a build number * Beta builds prefixed with "-beta" + a build number * RC builds prefixed with "-rc" + a build number With this versioning pattern, as soon as a ci build is uploaded to a nuget feed visual studio will never be able to identify that an alpha/beta is available. The main solution to overcome this is by using different feeds however that adds additional complexity But yes it would need to be supported on the api level and then used by clients when doing searches just like the preview flag

[jeffkl]

@thompson-tomo I believe 1.0.0-ci being lower/higher than 1.0.0-alpha is just a limitation of Semantic Versioning.

Would a version schema like this work for you?

1.0.1xx-ci
1.0.2xx-alpha
1.0.3xx-beta
1.0.4xx-rc
1.0.5xx

Whatever is appending the build label could also treat ci as 1xx and so on. Then when you push a package, 1.0.200-alpha would be higher than 1.0.100-ci. And 1.0.101-ci would be higher than 1.0.100-ci. Version ranges would also work

(1.0.100-ci, 1.0.200-alpha] >= 1.0.100-ci and < 1.0.200-alpha

1.0.* would only match 1.0.500 and greater

1.0.*-* would match the highest prerelease version including -ci, -alpha, -beta, or -rc.