Archi Upgrade Procedure

[kkosienski]

Hi All,

We are using Archi 4.6 with the CoArchi plugin to collaborate on a model we use to manage are architecture content within our EA/SA practice. We have multiple architects contributing content to the model managed in GIT. We are looking to upgrade our distribution of Archi and the CoArchi plugin but on past attempts have run into issues with having different versions of archi deployed and actively trying to collaborate on the same model using CoArchi plugin. Typically the newer installation fails on initial model import. Is anyone aware of an upgrade procedure or process that may be published that we possible can leverage to help facilitate an upgrade?

[Jean-Baptiste Sarrodie]

Hi,

There are two possible courses of action (pun intended) depending on your current and target version of Archi:

If both the source and target use the same internal storage format, then different versions of Archi can cohabit safely, but of course new features will be usable only on the newer version (but won't be erased or impacted by earlier versions still in use). Actually the internal storage format is not made explicit outside of the source code and some discussion Phil & I might have on GitHub. But the same version was used for Archi 4.6, 4.7 and 4.8 (it changed with 4.9).

If the source and target version of Archi use a different internal storage format, then the safest migration path would be the big bang and I highly recommend it in your case.

In this case:

• Everyone publish their changes
• You refresh to make sure you have the latest version of the model on your workstation
• Everyone upgrades to the newest version of Archi/coArchi
• You open the model, it will be automatically updated to the newer internal format
• You commit this change (using an explicite commit message such as "Model migration to Archi 4.9 format") and publish it
• Everyone should refresh the model to be sure to have the latest version updated. At this point, they will most certainly be prompted to commit their changes (ie. the internal model upgrade that happened behind the hood), they should refuse to commit but still continue with the refresh.

This last step is not mandatory because if someone starts working on the model, it will commit and merge fine with the remote version, but that's good to do it just to avoid any potential issues.

That been said, and based on some tests on my side, it might be possible to have Archi 4.6 (+coArchi 0.7.x) and 4.9 (+coArchi 0.8.x) to cohabit for some time if you don't use new features (specialization and custom images). And if you do, importing/refreshing the model and saving/publishing it from Archi 4.6 will remove any of them anyway. This should give you enough time to migrate everyone, and only then you'll be able to use new features. In the meantime, people will be annoyed by "unvisible" changes (due to automatic internal model upgrade/downgrade) and will be asked to commit even if they never changed anything, but (thanks to coArchi 0.7.x) this shouldn't block them. Use at your own risk, do a backup, blah blah blah... ;-)

Regards,

JB