Lower the required version of json.net if possible

[bjorn-ali-goransson]

Is requiring Json.Net to be at least 7 really necessary?

[gmarz]

Ideally, we'd like to keep up with the latest version of Json.NET and avoid surprises like #1462, since one can upgrade via other dependencies. At the same time, we'd also like to avoid supporting two major versions until we have a proper way to test both of them.

Thoughts @Mpdreamz?

[bjorn-ali-goransson]

Testing several version of dependencies would definetely be cumbersome, but
on the other hand, forcing people to upgrade dependency x just because a
new version comes out pushes (other kinds of) cumbersomeness to the library
consumers.

Isn't there some testing tool allowing for testing version matrices of
NuGet dependencies?

2015-08-18 22:20 GMT+02:00 Greg Marzouka notifications@github.com:

Ideally, we'd like to keep up with the latest version of Json.NET and
avoid surprises like #1462
#1462, since one can
upgrade via other dependencies. At the same time, we'd also like to avoid
supporting two major versions until we have a proper way to test both of
them.

Thoughts @Mpdreamz https://github.com/Mpdreamz?

—
Reply to this email directly or view it on GitHub
#1521 (comment)
.

[andersosthus]

@bornemix That goes both ways :) If ES sticks to JSON.NET 6, but some other library you use require JSON.NET 7, you can have the same issue, though not as likely unless you were already using deprecated APIs.

Personally, I prefer it if libraries stay on latest, but that's mainly because we prefer to be as caught up as possible on all our libraries. Though I do understand that it might not be the norm.

[bjorn-ali-goransson]

You don't need to "stick" with a single version, but instead provide for a
minimum version (like WebAPI does with Json.Net). Anyone having troubles
needs to (and probably will) upgrade.

2015-08-18 23:55 GMT+02:00 Anders Østhus notifications@github.com:

@bornemix https://github.com/bornemix That goes both ways :) If ES
sticks to JSON.NET 6, but some other library you use require JSON.NET 7,
you can have the same issue, though not as likely unless you were already
using deprecated APIs.

Personally, I prefer it if libraries stay on latest, but that's mainly
because we prefer to be as caught up as possible on all our libraries.
Though I do understand that it might not be the norm.

—
Reply to this email directly or view it on GitHub
#1521 (comment)
.

[Mpdreamz]

When Json.NET 7 initially came out some of its internals changed in a way that also caused NEST to break.
We did initially committed a dependency range of [6,8 but for that to work we would also have to downgrade our referenced version. We reasoned that we rather build and test against the latest and greatest and not hold anyone back from upgrading to JSON.NET 7.

Also when starting blank projects Nuget will sadly still opt to install JSON.NET 6 and therefor perpetuating its usage. Interesting discussion on this behavior

For NEST 2.0 we are are only going to support Json.NET 7 (and possibly up), however we'll continue to support NEST 1.x for as long as Elasticsearch 1.x receives patch releases.

I'm not opposed dropping our dependency in 1.x down again to 6.0 but we need to invest in making the changes to our CI so that we build and test against both 6.0 and 7.0. We currently do not have enough cycles to implement that though.

I have to ask though, whats causing your requirement to stay on JSON.NET 6?

[bjorn-ali-goransson]

External dependency, in this case EPiServer. I guess though that there are
two easy solutions for me and everyone in the same situation, though:

1. Force NuGet upgrade of Json.Net (this is what I did)
2. Downgrade Nest.

2015-08-19 12:06 GMT+02:00 Martijn Laarman notifications@github.com:

When Json.NET 7 initially came out some of its internals changed in a way
that also caused NEST to break.
We did initially committed a dependency range of [6,8 but for that to
work we would also have to downgrade our referenced version. We reasoned
that we rather build and test against the latest and greatest and not hold
anyone back from upgrading to JSON.NET 7.

Also when starting blank projects Nuget will sadly still opt to install
JSON.NET 6 and therefor perpetuating its usage. Interesting discussion on
this behavior NuGet/Home#1192

For NEST 2.0 we are are only going to support Json.NET 7 (and possibly
up), however we'll continue to support NEST 1.x for as long as Elasticsearch
1.x receives patch releases.

I'm not opposed dropping our dependency in 1.x down again to 6.0 but we
need to invest in making the changes to our CI so that we build and test
against both 6.0 and 7.0. We currently do not have enough cycles to
implement that though.

I have to ask though, whats causing your requirement to stay on JSON.NET
6?

—
Reply to this email directly or view it on GitHub
#1521 (comment)
.

[Mpdreamz]

Cheers, handy to know EpiServer is still on 6 for now.

Will leave this ticket open, its not something we can pick up in the foreseeable future though. Thanks for posting your workaround 👍

[andersosthus]

@Mpdreamz regarding building and testing against several JSON.NET versions:

Are you looking for as VS solution so that a contributor can run tests against all JSON.NET version or are you wanting to do this only on the CI server (and then use latest for development)?

If it's the latter, I can take a look at modifying the build scripts to do that (really getting into FAKE lately :)), though if you want it against all of the 6 series and 7 series, the test suite will probably take a fair bit longer to run.

[Mpdreamz]

Definitely the latter! Any effort here would be appreciated!

[Mpdreamz]

closing this in favor of: #1694 to track and discuss testing multiple version of json.net