1061 update nuget packages #1062
Conversation
Refactor some tests to fix obsolete warning messages
Some of the changes did not work on VS2015 like: if (jsonContract is JsonArrayContract arrayContract)
|
@heldersepu - this will be a good one to discuss further. Dependency versions seems to come up a lot. My philosophy up to now has been to depend on the minimum versions required for the code to work. This allows application developers to upgrade dependencies at their own pace. For example, I don't want to force application developers to upgrade to the latest version of JSON.NET in order to use Swashbuckle. I'd prefer SB to specify a minimum version and to work with all versions after that. So, the upgrade path for common dependencies is left in control of the application developer. But, given how frequently this comes up, I don't think it's quite as simple as that :( |
|
@heldersepu - #1063 might be preferable as it fixes #1041 and only forces consuming applications into a single major version upgrade instead of 4 major versions (the latter is going to be a more daunting prospect and may even be prevented by other dependencies). This way, SB should work for any version of Newtonsoft upwards of 7.0.1. At least until the next breaking change is released by Newtonsoft :) |
|
@domaindrivendev In my experience not updating to latest often sets you up for a headache. The time will come when you need that new feature on the latest version, or a fix for a security issue, you might be in a tight deadline but now you have to refactor a lot, just because you are now jumping from v4.0 to v9.5 We are not removing the old versions of Swashbuckle from Nuget. Anyone interested on older versions for compatibility reasons can get one of the old versions. |
|
I should have clarified, I meant my philosophy specifically when developing libraries/packages. Of course in an application, I would strive to keep things up-to-date. But when you're wearing the hat of a package developer you need to think very differently. You simply can't force consumers of your package into the latest version of everything. |
|
Ironically, it's this philosophy on the part of the package developer that gives the application developer the best chance of "updating early and often". For example, imagine you had a dependency on PackageA and Swashbuckle. Then for argument sake let's say PackageA was a little behind and only supports Newtonsoft <=7.01. Now, if we make SB depend Newtonsoft >=10.0 |
|
in its next version, then the application developer can't upgrade SB until the author of PackageA updates its dependencies. |
Update most of the Nuget dependencies, we still behind on a few because the Swashbuckle.Core is on .NET Framework 4.