Nuget RavenDB.Client 1.0.972 - running with Newtonsoft.Json 4.5.9

[Sean Feldman]

Hello,

I have another package that is using Newtonsoft.Json 4.5.9 (Thinktecture.IdentityModel) and can't install RavenDB.Client 1.0.972 because it relies on Newtonsoft.Json 4.5.7. As a workaround, I have followed the following steps:

1. pulled RavenDB.Client 1.0.972 w/o dependencies

2. manually pulled down NLog

3. changed assemblyBinding for Newtonsoft.Json 4.5.7 to 4.5.9

Would be there a better approach and how to avoid this dependency nightmare. 

Thank you,

Sean

PS: Also, noticed that the unstable version has no dependencies. Is this the direction that be expected in the future? Wonder how far unstable from stable.... :)

[Kijana Woodard]

Hi Sean,

Yeah, they've taken care of this in the unstable. Version 972 was a bone to keep the stable branch working with web api. Unfortunately, json.net has rev'd again since then.

[Sean Feldman]

Hi Kijana,

I'd like to introduce Raven into a small project which is a production project, and unstable doesn't sound like the right way to go... I'll keep moving with workaround until hit surprises, thought this is an unnecessary complication, especially when trying to convince people to switch to Raven :)

Sean

[Kijana Woodard]

Yes. It's unfortunate. 1.2 is ~2 months away, but json.net keeps breaking stable.

[Chris Marisic]

The unnecessary complication comes from James Newtonking and his terrible revision management, and just insistence on inserting breaking changes in his software.

Of course I also blame MIcrosoft for not releasing a json serializer that doesn't suck.

[Kijana Woodard]

Your comments about JNK make me think Microsoft should have picked something else. But what? Oren and others have been less than enthusiastic about service stack too.

And you're right. Json.net is considered fantastic by most .net devs because the framework json story is so poor.

[Chris Marisic]

Right, most developers, probably 98%+ never actually NEED JSON.NET. They merely need to de/serialize json and don't care how it's done. Most end up using it just because they know the JavascriptSerializer is brutally slow.

RavenDB on the other hand needs deeply low level json parsing in addition to highest performant as possible. So for most developers never touch the guts of JSON.NET and are entirely oblivious to the breaking changes that continually happen inside of it.

[Kijana Woodard]

Sean,

Any chance your project go live is post two months? If not, the unstable is less unstable now since feature freeze was last week. It's in heavy testing and running in production on most hibernating rhinos properties. In addition, several brave souls have been running in production with 1.2 for months.

There's enough good new stuff in there that I would start a new project on unstable. The only reason I haven't switched is because I run on RavenHQ which won't upgrade until well after 1.2 turns officially stable.

[Sean Feldman]

Kijana,

Glad you brought RavenHQ - this is what we are using as well.

I will continue with the workaround (since no one has commented about other options of doing it) and switch over to 1.2 once it's stable and supported by RavenHQ. 2 months is not critical in our case.

Thank you,

Sean

[monsters]

A fair reply. Thanks for the great product James.

Bill.

On Thursday, 27 September 2012 23:26:26 UTC-4, James Newton-King wrote:

Chris Marisic you have been saying some strong statements about me. A friend pointed me here to respond.

The last breaking changes I know of are from the major release of Json.NET 4.5 where I clearly announced that there would be breaking changes and I gave configuration options and instructions to help people upgrade. Following feedback, including some from RavenDB, the release immediately after that I added a couple of additional options to make switching to Json.NET 4.5 even easier. That was over 6 months ago. In the many minor releases of Json.NET since then I have been careful about not introducing any breaking changes outside of low impact bug fixes and I have not heard any complaints about breaking changes from people upgrading between Json.NET 4.5 releases.


~ James Newton-King

[Chris Marisic]

We've discussed this directly on twitter previously. I made it clear I feel you made wrong choices in revision/version management of your project. It's your project so clearly you're entitled to do anything you wish, I've just seen RavenDB continually take flak over it for the very reasons I feel the choices were wrong. I strongly believe if you had followed semantic versioning rules most of these issues could have been avoided.

Users understand software that depends on NHibernate2 cannot be expected to magically be compatible with NHibernate3.

Users expect that they can upgrade to NHibernate2.5 without issue.

This is the fundamental fallacy of you releasing a major version as 4.5 and not 5. I also believe previously you've introduced breaking changes even in patch revisions. IMO neither are acceptable for a public dependency. This is the equivalent of Microsoft releasing Service Pack 1 for an operating system and Microsoft Word can no longer be used.

On Thursday, September 27, 2012 11:26:26 PM UTC-4, James Newton-King wrote:

Chris Marisic you have been saying some strong statements about me. A friend pointed me here to respond.

The last breaking changes I know of are from the major release of Json.NET 4.5 where I clearly announced that there would be breaking changes and I gave configuration options and instructions to help people upgrade. Following feedback, including some from RavenDB, the release immediately after that I added a couple of additional options to make switching to Json.NET 4.5 even easier. That was over 6 months ago. In the many minor releases of Json.NET since then I have been careful about not introducing any breaking changes outside of low impact bug fixes and I have not heard any complaints about breaking changes from people upgrading between Json.NET 4.5 releases.


~ James Newton-King


On Thursday, 27 September 2012 00:30:57 UTC+12, Chris Marisic wrote:

[James Newton-King]

It's your project so clearly you're entitled to do anything you wish, I've just seen RavenDB continually take flak over it for the very reasons I feel the choices were wrong. I strongly believe if you had followed semantic versioning rules most of these issues could have been avoided.

RavenDB's problems have nothing to do with semantic versioning, they're caused by it requiring an old version of Json.NET that is incompatible with what other popular projects are using. Web API needs Json.NET 4.5, RavenDB breaks with 4.5. Whether it was called 5 or 4.5 changes nothing.

You are upset about a red herring.

[Justin A]

While James is here in this thread, Oren ... would there be any scenario you would see that would remove your 'internal' JSON.Net code and once more make JSON.NET a dependency?

NOTE: I understand you wrote a post sorta about this, recently: RavenDB 1.0 & Newtonsoft.Json 4.5.7

[Oren Eini (Ayende Rahien)]

Probably not. I am trying to minimize our external dependencies as much as possible.

JSON.NET being a successful library is being used all over the place, and I don't want to get into additional issues with versioning, even if they can be resolved using assembly redirects, it is simpler not having the issue.

[Chris Marisic]

I am most certainly not upset about a red-herring. If the breaking changes you introduced released JSON.NET 5.0, then 6.0, then 7.0, then 8.0 people would understand that your project is changing in nonbackwards compatible manners.

The issue is transparency. And correspondingly, the lackthereof.

Users see raven dependent to 4.0.8, users readily expect JSON.NET 4.5.9 to be compatible. This then becomes "raven's fault" that they are arbitrarily out of date and all they need to do is nuget update. If users saw the truth which is raven depends on 4.0.8 and the current version is actually like 8.0, people would no longer automatically assume there's a trivial 2 second fix. Would people likely request support to for 8.0? Yes. But users would actually be informed then as opposed to being unknowingly using JSON.NET 8 not really 4.5.9 and that there were an entire series of breaking changes between then.

[Kijana Woodard]

Remember when .Net 1.0 was supposed to "End DLL Hell!". We were so naive. ;-)

[Oren Eini (Ayende Rahien)]

To be fair, the dll hell problem was 10000 times worse.

[Kijana Woodard]

Oh Yes. I don't want to go back! :-)