Fix up some NuGet private package definitions #24314
Merged
+3
−3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We produce a number of pre-release packages for partner teams to get copies of certain APIs we haven't ratified. We never produce 'stable' versions of those packages because they aren't stable in any meaningful way. But sometimes, you want to mix those pre-release packages and their equivalent stable packages in the same build, which is something that ASP.NET needs to do. This means that we can't use strict package version rules that require exact versions everywhere, or else a 1.2.3-beta1 package will be "incompatible" with 1.2.3 the final release. The easiest fix for this is to change the package dependencies that go from private unofficial packages to official packages as being a "or higher" version requirement, so it works. There's no promise this will work at runtime, but since there's prerelease packages in the mix in the first place there never really was such a promise.
Member
Author
|
@heejaechang or maybe @jaredpar a quick review? This is changing some packaging for internal-only packages. These are consumed by Razor that end up with their projects referencing both these (that we produce prerelease only) and also packages that are their shipping ones that reference real versions. This avoids conflicts in that case. |
jaredpar
approved these changes
Jan 29, 2018
Member
|
Did you consider adding a comment to why we have this versioning policy somewhere? |
Contributor
|
tagging @rynowak as FYI |
heejaechang
approved these changes
Jan 29, 2018
Member
|
Groovy! Thanks @jasonmalinowski |
Member
Author
|
@jaredpar The PR message here is the commit message, so that will hopefully help... |
jasonmalinowski
deleted the
fix-remote-unofficial-dependency-versioning
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We produce a number of pre-release packages for partner teams to get copies of certain APIs we haven't ratified. We never produce 'stable' versions of those packages because they aren't stable in any meaningful way. But sometimes, you want to mix those pre-release packages and their equivalent stable packages in the same build, which is something that ASP.NET needs to do. This means that we can't use strict package version rules that require exact versions everywhere, or else a 1.2.3-beta1 package will be "incompatible" with 1.2.3 the final release.
The easiest fix for this is to change the package dependencies that go from private unofficial packages to official packages as being a "or higher" version requirement, so it works. There's no promise this will work at runtime, but since there's prerelease packages in the mix in the first place there never really was such a promise.
This is an infrastructure only change (and only changing some non-shipping NuGet package metadata), so no ask mode is required.