Editors' R.O.T. _001 — Never Update in the Middle of a Project

[Kevin-Monahan]

"YOU UPGRADE ANY SOFTWARE MID-PROJECT AT YOUR OWN RISK. Bad things can happen, work cannot get done, great frustration can be had, clients can get mad and payments might not be made. There, you’ve been warned. And backup your system."

-Scott Simmons, Editor

From the Editor's R.O.T.

It is never a good idea to update in the middle of a project. This is an R.O.T. I personally learned while gaining my certification at Avid Boot Camp back in 1997. It is not a new R.O.T., nor is it specific to Premiere Pro. With every NLE I've ever cut with, it is always an issue. It will probably always be on an editor's radar as an issue, but our developers are working hard to make this problem go away permanently.

Let's hope they solve problem for project updating permanently soon.

We can all help boost that process by joining me in upvoting the following feature request: Stop Breaking PPROJ files There is no reason each update should require prproj files to ONLY work in...

Until then....

How do you deal with this?

• If you can, finish up the project in the software version it was created in.
• Create only new projects in the updated software once you decide to update.

But you are never "between" projects....

• You can always use a previous version of your software to finish off or make changes to a previous version.
• Personally, I keep multiple versions of my NLE installed for such situations.

Why is this an issue?

• NLE Software is very complex.
  • Since NLE software is the most complex kind of software running on your computer, it is also susceptible to major changes in the software code. Sometimes the older code in a previous version's project file, might conflict with changes made in the new project file format. This results in things like unexpected behavior.

• The more complex a project is (feature, doc, multicam heavy projects), the more likely unexpected behavior (like crashing, freezing, memory leaks, etc.) will occur after the project file format is updated.
• Project updates happen more frequently, and therefore, the problems that come along with updating also occur more frequently:
  
  

"This is ridiculous, I like to update my premiere to the latest update as software usually speeds up but in the case of premiere each update breaks your files, slows down, had new featured FORCED in, let us move our files back to older versions and interoperate THIS WAY. This is maddening."

-Anonymous

I can understand the frustration coming from people like Anonymous. The frustration increases even more when you realize you can't fully use some of the new features of released software. You have to postpone updating in order to preserve the safety of the project file. Considering this, I will certainly advocate for a better situation for him or her.

You still need to update between projects because of a feature or bug fix. What's the safest way to do so?
I would advise creating a brand new project and importing the previous version's project into the new one. I found that others in the community do the same.

This broad step can bridge the gap between the old code and the new. You'll probably have better success than merely updating the project file, which can corrupt the file. Of course, always do this step with backups in hand so that if something goes wrong with this project file, you can always revert to the original and complete the project in the previous versions' software.

Resources

• Here is an article where veteran editor and my personal colleague, Scott Simmons advises the very same thing: How to upgrade your NLE software mid-project. Not that you should.
• Here's an article I wrote on the same topic: Updating and backing up project files: best practices

Feel free to discuss this topic below.

Regards,
Kevin

[Kevin-Monahan]

To fully solve this issue, having a good way to revert to the previous version's project file should also be approached. Here's what Premiere Pro's Engineering Manager has to offer:

"There are a couple of possible options that we are looking into and discussing with editors both shorter and also longer term that pose unique challenges:

1) Keep the project file compatible across a version so that, for example, version 19 won't have project changes for the entirety of that version. That will allow for compatibility for that version regardless of which version of 19.x you own. Of course this would limit the work we can do that impact project files until the next major version

2) Create a feature that allows for an XML level export with support for a baseline of edits and effects only that would be backwards compatible moving forward."

-Reg Santo Tomas

Thanks,
Kevin

[sebrame]

While a great rule, for some of us it's not very realistic. I can't remember the last time that we didn't have an active project or several in progress. Also, such a rule doesn't, in my mind, excuse the release of an alpha with critical bugs.

We've been an "Adobe House" since sometime before Premiere 5.0, and being that we've invested many, many thousands of dollars in Adobe software, we'll probably stay one - but the current repeating trend is very troubling. Releasing an alpha with critical bugs, and then basically blaming it on us for upgrading in the middle of a project isn't cool.

I understand that you've got a tough job trying to keep the torch bearing mob from the door, and you do a wonderful job. Now if your engineers could up their game...

[R Neil Haugen]

This is where Kevin's comments about ... when you must update, how to do it safely really come into play.

You still need to update between projects because of a feature or bug fix. What's the safest way to do so?
I would advise creating a brand new project and importing the previous version's project into the new one. I found that others in the community do the same.

This broad step can bridge the gap between the old code and the new. You'll probably have better success than merely updating the project file, which can corrupt the file. Of course, always do this step with backups in hand so that if something goes wrong with this project file, you can always revert to the original and complete the project in the previous versions' software.

I've been following this since the original CC came out, and I've normally been able to update a project. And unlike say Resolve, we can have multiple versions of Pr on one machine. Installed and working. So being able to test in a new version before committing to it is good ... but that's between major version changes or "upgrades", build numbers shifting from say 12.x to 13.x.

On an update within a version ... I still normally create new project files, import the old project. Takes a very little time ... and ... it just tends to work.

Neil

[Kevin-Monahan]

sebrame,

While a great rule, for some of us it's not very realistic. I can't remember the last time that we didn't have an active project or several in progress.

I realize that there are a good number of us that have projects that are always in progress. That is a problem that contradicts this R.O.T.

You'll have to develop one of your own for dealing with such a thing. It is a problematic position to be in if this describes your workflow.

Please take a look at Simmons' comments around that issue. Paraphrasing, he admits that most of us update in the middle of projects anyway, even though we know it's not the correct thing to do.

I think the way I would deal with this is to update a project via creating a new project and then (after dumping media cache and prefs) importing the old project into the new one. You'd want to have a couple of backups before attempting this, I think.

• Also, such a rule doesn't, in my mind, excuse the release of an alpha with critical bugs.
• Releasing an alpha with critical bugs, and then basically blaming it on us for upgrading in the middle of a project isn't cool.
• Now if your engineers could up their game...

To clarify, I'm speaking as an editor in these R.O.T. "chats", not as an Adobe employee in this scenario. If you'd like to address the quality of a release, hit up the devs here. Cheers.

Kevin

[Liv30712427yo8w]

I just had this amazing experience:

I asked for help via the Adobe suport, some tech helper connected to my machine via remote and (without asking me) updated my Premiere. While the update was running I showed them this page, and they said: Don´t worry, you just updated your project (!). They also said this: This Premiere version is stable. Lol.

Well, I was too slow to cancel the process, Premiere updated, and now my LUTs are screwed...

How the story ended? I just installed DaVinci.

[R Neil Haugen]

What do you mean your LUTs are screwed? 

As if you aren't seeing them in the drop down lists now, that's user error ... you probably didn't put them in the correct place for user LUTs. Which is NOT in with the 'built-in' LUTs.

My LUTs are usable across a whole range of versions without issue. And between AfterEffects, Premiere, and MediaEncoder ... updating has no effect.

As someone who works for/with/teaches pro colorists, I've used, as in worked in, and tested and taught some Resolve for years. Resolve isn't a "magic bullet", it's got it's own different problems. And I get a hoot when people are upset that Premiere isn't "properly" supporting ProRes RAW, and are going to Resolve.

Which has no ProRes RAW capability At. All. And from comments from Resolve staffers, ain't gonna have it either.

Multicam is typically called a relative strength for Premiere over Resolve also. Yep, Resolve has more grading tools. But then, trying to get parity of image between Fusion and the color page is even harder for many Resolve users than between Ae comps and Premiere.

They're just tools. Fancy hammers. Leave the emotions behind. Save your sanity.