Consider the following scenario: there is a package (e.g. Super.Log) which goes through version 0.1 to 0.9 and is now approaching release. Developers publish a version 0.1-rc, and this becomes a problem for other packages that reference Super.Log.
So if we have another package MyComponent version 0.6 that listed Super.Log in its dependencies, it can no longer list the latest (and best) Super.Log version because NuGet policy does not allow referencing pre-release versions of other components from non-pre-release packages. Developers of MyComponent will have assign a version 0.7-beta or something in order to be able to use Super.Log. This will affect all MyComponent users who regularly updates their dependencies using Update-Package command. All pre-release components must be installed or updated by explicitly choosing pre-release option, so by default MyComponent users will not be getting most recent version.
As a workaround some package publishers publish them twice: as pre-release and as a regular version, take a look for example at Simple.Data.Core: https://www.nuget.org/packages/Simple.Data.Core/ It has duplicate versions for all its recent packages because of this. But Simple.Data does not have any external package dependencies, and if it had a dependency on another package with pre-release versions, such workaround would not be possible.
I find this policy to be prohibitive for frequent incremental updates. Moreover, since it has a transitive nature, one little package may decide version numbering for the whole chain of related packages. I can see two ways to improve it:
1. Turn an error condition into a warning condition, so developers are notified about using pre-release packages but are not forced to change their version policy.
2. Introduce an additional option to "NuGet Pack" command to suppress an error condition due to use of pre-release packages.
Comments: We need to think through the design.
So if we have another package MyComponent version 0.6 that listed Super.Log in its dependencies, it can no longer list the latest (and best) Super.Log version because NuGet policy does not allow referencing pre-release versions of other components from non-pre-release packages. Developers of MyComponent will have assign a version 0.7-beta or something in order to be able to use Super.Log. This will affect all MyComponent users who regularly updates their dependencies using Update-Package command. All pre-release components must be installed or updated by explicitly choosing pre-release option, so by default MyComponent users will not be getting most recent version.
As a workaround some package publishers publish them twice: as pre-release and as a regular version, take a look for example at Simple.Data.Core: https://www.nuget.org/packages/Simple.Data.Core/ It has duplicate versions for all its recent packages because of this. But Simple.Data does not have any external package dependencies, and if it had a dependency on another package with pre-release versions, such workaround would not be possible.
I find this policy to be prohibitive for frequent incremental updates. Moreover, since it has a transitive nature, one little package may decide version numbering for the whole chain of related packages. I can see two ways to improve it:
1. Turn an error condition into a warning condition, so developers are notified about using pre-release packages but are not forced to change their version policy.
2. Introduce an additional option to "NuGet Pack" command to suppress an error condition due to use of pre-release packages.
Comments: We need to think through the design.