Save as previous version

[yavork]

Please Allow Revit files (either projects or families) to save in previous versions of the program. (Or at least the Families??)

With so little new features I cannot believe Autodesk can justify upgrading the project database every year?

(If database is not the right term - please excuse my negligence)

I am sure it can easily go for 3-4 years before some of their "new features" requires upgrade to the database. Or find different workaround.

It has been asked and requested so many times on the forums and whitelists I am surprised is not first on the list.

[Anonymous]

 Yes it was the US imperial. I am not sure if there is a difference. But we use the Ultimate design building suite and we are on subscription. We get one version of Revit that has all on one. So MEP, Arch, Struct are all bundled under one Revit application.

[Mirko.Jurcevic]

As I stated somewhere else, this is Autodesk's corporate policy. Why? Because, the biggest AutoCAD competitor is earlier version of AutoCAD.

Typical user comment: "Why should I buy latest (insert any Autodesk software here...) version when there are so few upgrades? My old licence works just fine. Also, new versions work slower on my machine as they require a lot of resources."

That's the mistake Autodesk made with AutoCAD (for example) and won't make it with Revit. That's why there is no backward compatibility.

Second reason(s) are in using more (software developer) resource to achieve backward compatibility. If there is no backward compatibility requirement they have free hands to do whatever they want (which is cheaper).

Nowadays, when it is no longer possible to buy permanent licence, only subscription, first reason is no longer valid (competitivity between software versions). So, the second reason now becomes first reason.

My suggestion is: at least stop changing the file (database) format at least in the 2-3year period.

[arch.sarah86]

totally agree

[sasha.crotty]

With regrets, as I am sure there are going to be a lot of people here who will be disappointed, I am archiving this idea. While we fully understand why this request is important and would be of great value to you, it is not feasible for us to add it to the Revit roadmap. Before you share your thoughts, I do ask that you please read my full response here as I will do my best to explain the reasons behind the decision.

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.

1. 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.
2. 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…
3. 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.

[pieter4]

I think this makes a lot of sense.

Ps: it's very much appreciated that the factory took the time to explain their decision in so much detail. 

[yavork]

Well too bad that even the families are not getting this feature. Too bad also that Autodesk cannot stay competitive with other BIM products and the gap seems is increasing: Back-Saving from ARCHICAD 20 to ARCHICAD 19

If they can do it why not you?

[bosborne]

Even families have had significant changes in the last 3 versions (DirectShape geometry, structural section parameters for instance) and may have changes in future versions (perhaps arrays with only one instance, number + text concatenation, etc). The same issue exists - pick backward compatibility or continual advancement.

Sent from my iPhone

[lionel.kai]

@sasha.crotty Thank you very much for taking the time to write your response. I realize that not every one of the thousands of ideas on this site can get this kind of attention in response, but when we do, it makes us feel like Autodesk IS actually listening and understanding our concerns.

You got me curious when you said "bug fixes often require format changes". Does this mean that you sometimes roll in "micro" format changes to update/service pack releases? Is this why having people on different update levels is not recommended (and can sometimes cause corruption of the project file)?

Also, is there some way to make the file format more "flexible"? In AutoCAD, when you save down, new features/objects (or even from verticals like Architectural Desktop, etc.) have "proxy graphics" or just don't show up when opened in previous versions. Would it be possible to have an option to open the file and get a report of stuff that (the previous version of) Revit didn't understand? Again, my main issue is reuse - not actually "working" in the saved-back model, so I don't care if the curved wall gets deleted, or if the "OR" Filter just gets removed from the View Template, or if the structural section properties disappear, etc. In my view, something is better than nothing (and if I had the time, I would have already written the add-in I suggested in my first post). If I was trying to insert a Drafting View from a newer file, and I got a dialog that showed a list of (DC & AS) Families that were missing (and gave me a chance to load corresponding families from the previous version), I'd be happy.

[yavork]

@bosborne - if you read how Archicad does it - if an element is not compatible with the previous version it deletes it. But you still get something workable. There is always a way to do if you really want it but obviously Autodesk lacks desire to satisfy majority of their customers... Case closed.

[Anonymous]

@sasha.crotty, this was great to read. Thanks for sharing in such detail. Not have to worry about version... now that sounds good! 

[JanUsinger]

---

yavork:

"if you read how Archicad does it - if an element is not compatible with the previous version it deletes it. But you still get something workable. There is always a way to do if you really want it but obviously Autodesk lacks desire to satisfy majority of their customers... Case closed."

---

I agree with yavork.

This is not about a smooth cooperation solution. This is for the odd occurrences where you need access a file/ family that is of a later version. It is okay if it is does not convert 100% perfectly.

I do appreciate that Sasha Crotty took the time to respond in detail to the idea.

Please review it again with the above comments in mind.

[Anonymous]

@JanUsinger

I wouldn't want the factory spending the time that would take to implement (and maintain this) for the "odd occurences". I can think of 10 things from the top of my head that would help my productivity immensely that I would much prefer take priority....and I would use on a daily basis. 

So whilst I am not opposed to this idea, I am opposed to it taking priority over what I feel are more important ideas.

[JanUsinger]

I hope you have voted your 10 ideas up.
🙂
Look, I did not say that this would be on the very top of my wish list. But I think Archicad handled this issue better than Autodesk.

[Anonymous]

I agree with Sunilpatil:

Backsaving to lower version of revit files are not at all possible

Its there business stratagy. thats it i can say. 

Backsaving is only Possible in Autocad Vesrions.

only business

every year a new version, every year a new format.

what about people who manage different project with different client who impose different release 

installing 2014 and 2018 activated by network licence seems impossible at all

[py_temp]

As I search "Save as previous version" is rejected and I understand that the Revit team need to update to fully function. But Revit family might not have to be a big problem. For example, I want to model in Revit 2018, but then I want to share my model to people in Revit 2017, just revit family generic model.

It shouldn't effect much of too many code change at the background because as I see. Revit always keep updates, but revit family seem not much.

[Sahay_R]

At least the families should be backward compatible. There are times where custom families need to be used between old and new Revit versions.

[lionel.kai]

@Sahay_R It would be nice if basic families (like Detail Components) could be saved down, but there are features that have been added along the way that would prevent some sharing (adding parameters, changing the way Structural Framing ends behaved in 2014, etc.). Unfortunately, I don't expect Autodesk to invest the resources required to manage that any time soon...

[umit_balaban]

I agreed also. We are working with 2015v. And we could find families 2015v. So at least for families, Autodesk can change the rule. New families created with 2016  or 2017 versions. 

[Anonymous]

It would be nice if Revit had the option of downgrading when saving to another version of the software, for example 2018 to 2017 and so on. We had someone build us millwork in 2018 and we couldn't open it because we are still using 2017 a downgrade when saving would be awesome.

[samuelsanf]

See https://forums.autodesk.com/t5/revit-ideas/save-as-previous-version/idc-p/6954018/highlight/true#M66...