+972 52-548-6969
RavenDB 4.x –> RavenDB 5.x compatibility considerations
The upgrade process from RavenDB 3.5 and earlier to RavenDB 4.x is not easy. This is because I made a conscious decision to not have backward compatibility between these versions. I made that decision because we had to be able to make massive changes internally in order to get to the targets that we set to ourselves. I actually discussed that decision in detail in a previous blog post and a talk.
Four years later, I still stand by that decision, but I also regret the spanner that it threw into the works. Migrating RavenDB applications to 4.x from previous versions is harder than it should. In retrospect, we probably should have invested the time in a compatibility layer that would make it easier to migrate.
I wanted to take a moment and talk about RavenDB 5.0, expected in 2020, and our plans for that release. We are going to be doing some minor cleanup of the API. Methods and classes that are marked as [Obsolete] will be removed. These tend to be at the very edge of the explored API and have been marked as such for quite some time. Beyond these change (which you’ll a clear and obvious alternative for), you aren’t going to need to do much at all.
Our goal for converting an application from RavenDB 4.x to 5.x is that the process is for 90% of the projects - Update NuGet packages, compile, you are done. For the 10%, it may mean that you need to make some minor changes. For example, change DisableEntitiesTracking to NoTracking if you are using the low level query API.
We also intend to allow at least the vast majority of operations to just work between 4.x client and 5.x server. In other words, even when you upgrade server versions, you aren’t going to have to upgrade the client version unless you want to use the new features.
There are also additional considerations that we have to take into account:
- RavenDB now have official clients for: .NET, JVM, Go, Python, Node.JS, C++. As well as a unofficial clients.
- RavenDB Cloud instances are maintained by us, and will be upgraded to newer versions on a regular schedule.
The cost of making a backward incompatible change at this point is too high for us to take lightly, and we are going to try very hard to avoid it. The move from 3.5 to 4.x was a one time thing that we had to do in order to continue evolving the product, not something that we plan again anytime soon.
We are also offering migration services for clients who want to move their applications from 3.x to 4.x.
Comments
Would it be too bad to leave obsolete props/methods but mark them as errors (using the related flag in the ObsoleteAttribute) so compilation will still fail but with an accompanying message pointing to the “new way”? I’ve found that to be a good compromise.
njy, That is also a breaking change, and something that would just mean that we'll remove them at a later point. We are going to provide guidance on that, and as I said, these are usually in the nooks and crannies of the API.
That's very good to hear Oren - RavenDB 4.0 has been something we have been excited about since the outset but it has remained out of reach because of the migration effort that we're still going through. Having said that, if we were not using RavenFS and Raven Authorization Bundle extensively, the effort would not have been that bad. Weeks rather than months.
We're nearly there though and despite the pain, I am grateful for the benefits in performance and stability (or at least I hope I will be!) because these benefits will be felt for many years to come.
Comment preview