What I would really like to know is the thought process behind using the oldest dependency version in a version range in .NET instead of the newest like literally every other package or dependency manager ever made. That design couldn’t be worse if it was designed to maximize security holes.
If you specify that e.g. a dependency should be between version >= 4.0 and < 4.1 in dotnet and there are versions 4.0.0 and 4.0.1 available pretty much all other systems choose 4.0.1 based on the idea that that will include a fix while dotnet chooses 4.0.0 based on the idea that that is “more stable”.
Ah, thats fair. I think thats fixable using wildcards in the packagereference in the csproj, but id need to check. I too would expect it to choose 4.0.1 unless a patch release needs a big update or something
What I would really like to know is the thought process behind using the oldest dependency version in a version range in .NET instead of the newest like literally every other package or dependency manager ever made. That design couldn’t be worse if it was designed to maximize security holes.
Care to elaborate? I dont fully follow ^^; Feel free to also dm me or something
If you specify that e.g. a dependency should be between version >= 4.0 and < 4.1 in dotnet and there are versions 4.0.0 and 4.0.1 available pretty much all other systems choose 4.0.1 based on the idea that that will include a fix while dotnet chooses 4.0.0 based on the idea that that is “more stable”.
Ah, thats fair. I think thats fixable using wildcards in the packagereference in the csproj, but id need to check. I too would expect it to choose 4.0.1 unless a patch release needs a big update or something