As the title says, I'd like to suggest to (re-)introduce the possibility to save an ArcGIS Pro project in a previous version.
I know - all users should always work with the same version to prevent compatibility problems. BUT: sometimes two different offices work together on the same project and those two offices have different versions installed for all their employees. Thus a single employee cannot simply use the same version as the employee of the other office. The compatibility problem is guaranteed - either between the two offices or within one office.
It should be possible to agree that project XY is created with ArcGIS Pro version xy. Those who are already a version further would simply need to save the project in the agreed version. Problem solved.
Therefore I'd like to suggest to re-introduce the possibility to save the project in a previous version of ArcGIS Pro.
While not ideal, you can create Project Packages at different versions.
@nadja are you specifically requesting a Save as previous major version? i.e. you are working in 3.x and you need to share a project with somebody using 2.x?
Because ArcGIS Pro follows the semantic versioning specification, all projects within a major release series (i.e. 2.0 - 2.9) are backward compatible, meaning that there is no need for save as previous.
If you are specifically requesting a save as from a major version back to another major version, that can be done by creating a project package as Barry has pointed out.
@BarryNorthey thank you, I know, but I find Project Packages a cumbersome way if you need to work on the same project...
@KoryKramer No, I'm requesting a Save a previous version in general. Meaning I can save a project created in 3.1.2 as 3.12 or 3.1.1 or 3.0 or 2.9.7 or 2.x.
I know of the backward compatibility, but if another office still works with 2.9.6 and we work with 3.1.2 the other office cannot work properly. We're in no position to demand of the other office to upgrade - we can ask them nicely, but that's about it. Save as a previous version is one of the things we're REALLY missing.
We recently had the exact issue and "solved" it with a project package, but it was far from an ideal solution. Therefore I don't think project packages are a valid workaround.
@KoryKramer Since a Project Package apparently involves saving copies of all the data referenced in the project, I feel this is not a good enough solution. It takes significantly more time and file space than using Save As with the project file.
If I am reading the Help correctly, not all data need to be packaged depending on how the data are sourced.
If this option is not checked, enterprise database data, UNC path data, styles, and connections will continue to be referenced once the project is unpacked.
I saved a project package with "share outside of organization" unchecked. It took 13 minutes to package, and the resulting package file is around 1.9 GB.
I tried packaging the same project with that box checked. Result was about the same.
For me this is still not a good replacement for Save As with backward compatibility. But it's better than nothing.
For reference, the sample project has 5 maps and 5 layouts with 2 feature classes and a basemap in each map. The data referenced is not in an enterprise gdb, but in a file gdb on another computer in my local network. The original project file is 297 KB.
I'm using Pro 3.3.1. I've been told by my organization that we need to switch back to 2.9 for reasons which are hopefully temporary. I've decided it will be better to recreate most projects from scratch if/when I need them, since Save As to 2.9 is not an option.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.