Also reduced the count of entries of the max iteration to 25. The main
issue that we're trying to solve right now is which approach is the best
with a small number of entries. Going up to 100 takes a loooong time,
and all of the dictionary-based approaches scale well above 10 or so
entries.
* Introduce RoutePattern
Introduces RoutePattern - a new parser and representation for routing
templates, defaults, and constraints.
This is a new representation for all of the 'inputs' to routing that is
immutable and captures 'out of line' information for defaults and
constraints.
This will allow us to unify the handling of constraints and values from
attribute style routes and conventional style routes.
- When a surrogate pair is about to be split down the middle we reduce the size of our split by 1 character. This way we split right before a surrogate pair. In the case of zero width joiners, if we split on a zero width joiner we still render valid bytes because the zero width joiner by itself can stand alone.
- Added tests for the various split cases.
#2470
* Refactorings for codefix
- Move some common code in SymbolApiResponseMetadataProvider
- Don't run diagnostics for 1006 if we are unable to parse a return type
Our policy since 1.0.0 has been to always cascade version updates in the packages we own. e.g. if Logging has a product change in 2.1.x, then Kestrel, EF Core, Mvc, etc also re-ship with the updated Logging dependency. This has been done for a variety of reasons:
* NuGet does not show updates for transitive dependencies, only direct ones
* NuGet does resolves the lowest compatible transitive dependencies
* ASP.NET Core ships to both .NET Framework (where transitive dependency version matters) and .NET Core (where it matters less if you use the shared framework)
While transitive dependencies is still an important scenario, this practice of always patching has led to bigger issues.
* High probability users will unintentionally upgrade out of the shared framework: #3307
* Conflicts with metapackages that attempt to use exact version constraints: aspnet/Universe#1180
* A quality perception issue: the high volume of new versions in servicing updates with only metadata changes has created the impression that new versions of packages may not be very important. It's also made it appear like there are more issues product than there really are.
* High volume of packages changing with only metadata changes. Of the last 301 packages published in a servicing update, only 11 contained actual changes to the implementation assemblies. (3.5%)
This change implements a system to verify a new, non-cascading versioning policy for servicing updates. This required changes to repos to pin version variables to that matter per-repo,
and to remove some of the restrictions and checks.
Incidentally, this should make defining new patches easier because it automatically determines which packages are or are not patching in the release.
This reverts our previous policy of cascading versions on all servicing updates.
This moves variables into the 'pinned' section, and points them to the latest
stable release (versions that were used at the time of the 2.1.2 release).
This reverts our previous policy of cascading versions on all servicing updates.
This moves variables into the 'pinned' section, and points them to the latest
stable release (versions that were used at the time of the 2.1.2 release).
This reverts our previous policy of cascading versions on all servicing updates.
This moves variables into the 'pinned' section, and points them to the latest
stable release (versions that were used at the time of the 2.1.2 release).
This reverts our previous policy of cascading versions on all servicing updates.
This moves variables into the 'pinned' section, and points them to the latest
stable release (versions that were used at the time of the 2.1.2 release).
James Newton-King
ASP.NET CI
Ryan Nowak
Justin Kotalik
N. Taylor Mullen
John Luo
Mike Harder
Kiran Challa
Doug Bunting
Pranav K
Nate McMaster