Why “Save as previous version” doesn’t work for Revit projects

“Can I save my Revit project for an older version” is the probably one of the most asked questions about Revit (along with “When do we get Revit for Mac” and “How can i override a dimension”) – Sasha Crotty, Revit Product Manager, posted a very nice explanation over at Revit Ideas as the explanation why this won’t be implemented:

First off, let me say that this is not a decision that we take lightly. Further, there is no motive that is not expressed in this post. Despite what a few posts here suggest, this decision has nothing to do with how we sell our products, nor is it a strategic move on our part. It is quite simply an exceptionally difficult (impossible?) technical challenge, which, were we to embark on fixing it, is unlikely to fully deliver on the expectations and experience that you deserve (more on this later). If backwards compatibility was an easy thing for us to do, we would do it in a heartbeat because we understand that this would enable workflows that are a true challenge today.

There are two ways we could approach the problem: freeze the file format or add converters that transform new data to old data to recreate the old file format. Let me address each one in turn.

To be quite frank, freezing the file format would significantly hamper the speed of Revit development as the majority of Revit features require changes to the file format. I took a quick look and by my estimation at least 14 of the top 20 ideas on this forum would require changes to the file format. Comparing our development build to the 2017 file, there are about 3,000 changes to the format. So, on average, there are over 10 format changes per development day. This also doesn’t account for the fact that one change can have a huge impact. For example, the ability to have OR in filters could arguably be reflected as one format change, but that change could impact hundreds of views and sheets.

If we had to wait 3 years to get significant enhancements you, it would also mean we would it would be another 3 years before we could make further improvements/corrections to features. We often hear feedback that we don’t improve the product fast enough; unfortunately this would aggravate, not alleviate the problem.

I also want to point out that we already make an effort to identify and work on improvements that don’t require a format change. These changes are shipped as part of our point (previously R2) releases. We’re excited that we are able to get these new features to you as soon as they are completed. That’s why we’re all here on Revit ideas right? So that we can get you the improvements you need. I, for one, don’t want to wait three years to make that happen.

So, approaching this from the other angle, why not save back to older versions? I’m going to give you three examples of why this is an exceedingly difficult technical challenge, and why, if attempted, it would not result in the behavior you would expect.

Imagine for their birthday someone gives your kid a gift of alphabet blocks in a fancy gift box that is just big enough to house the blocks. The next year, someone else gives them a set of nicer blocks, but the blocks are 5% bigger in size. You want to keep the new set, but store them in the old box, but no matter how you try they just won’t fit. In fact, if the box housed 36 (3x4x3) original blocks, the box will only house 12 (2x3x2) new blocks! You could start sawing the blocks I suppose, but I think that defeats the purpose of alphabet blocks. File formats work in a similar way, a small change in the definition can have a huge cascading effect on the look and behavior of the file.

So why is the impact so big? Let’s take our OR in Filters example again. In a greatly simplified solution, the change from AND to OR could be stored in one new true/false property of filters (true = AND, false = OR) in Revit X+1. Of course, Revit X has no idea about this property, so as far as Revit X is concerned all filters are AND. Now imagine saving back a file from Revit X+1 to Revit X where you’ve used OR filters in 10, 20, 100? views. If we literally copied the filter conditions back to the Revit X format, suddenly your filter would be an AND filter. What happens to those views? Elements change color. Or worse, elements appear/disappear. Schedules change. I could go on. Ok, so that’s not a valid solution. Can we have developers write code that converts OR filters into AND filters and saves them that way? I’m a CompSci major and let me tell you – this is not straightforward code to write. And in some more complex cases I’m not sure it’s possible to write it in a way Revit X would understand. This is why OR filters are being requested in the first place, right? Now imagine doing this for every one of the 3,000 changes…

If that hasn’t convinced you, here’s a simplified element-based example. Friendly reminder: in Revit geometry is derived, not primary, data, so it’s not necessarily even stored in the file. In a world where Revit X only knows how to create linear walls and Revit X+1 introduces arc walls, what would happen if you took a Revit X+1 arc wall and saved it to Revit X? Because Revit X code has no idea how to use the extra data, your arc wall would show up in Revit X as a linear wall!

So at least for model objects, if we can’t write back to data, can we somehow save the exact geometry? Maybe (assuming the geometry kernel hasn’t changed), however this would mean that all of the intelligent behavior that you expect with Revit would be gone. So the arc wall would show up as an arc, but you wouldn’t be able to change it and Revit wouldn’t know how to make it act like a wall (e.g. clean up wall joins, etc). It would be a geometry that does not understand that it is a wall, so at that point what we have is un-editable CAD, not BIM. Exporting to IFC and importing it in the earlier version will give you at least the same, and likely much better, geometry consistency.

All this is to say that if we were to save backwards without freezing the file format, we would be unable to guarantee consistency of view settings or contents and it will result in the loss of intelligent behavior for elements. In other words, views would look different and elements would be frozen. The amount of work to achieve this “broken” state would also be huge. Giving you an unpredictable backwards save would not really help you with collaboration problems, in fact, it would quite likely cause errors in your deliverables. We don’t consider this an acceptable solution from a customer experience perspective, which is why we have chosen not to pursue it.

So that brings us back to freezing the file format as the only option we can consider. I mentioned earlier that this would slow down our development process because it makes it harder for teams to fix bugs (yes bug fixes often require format changes) and hinder our ability to give you the improvements being requested right here in Revit Ideas. In truth, we are looking to change the process in the other direction. We want to give you the latest and greatest as soon as it is available. We realize that that means reworking our install infrastructure and experience so that it is easier for you to get the latest version and increasing the reliability of upgrades so that you are able to trust the quality of the upgrade. We have not done a fantastic job of this to date, so there is a lot of space for us to improve. The ideal state is the Google Chrome experience. How many of you know which version of Chrome you’re running? We realize that there is a lot more complexity to installing and updating our software than Chrome, so I am not implying that this is the right solution, but that kind of simplicity of experience is the direction we want to pursue. Wouldn’t it be nice if you didn’t have to care about Revit versions in the first place? We think so and that’s why we’re archiving this issue. We understand that there is a problem, but we believe there is actually a better solution than backward compatibility.