There are two easy ways, in fact - one from the user interface, and the other from the command-line.
From the user interface, simply navigate to Admin > Settings, and right at the top of the page you should see the full application version listed. See:
As for the command-line method, I *think* this task is old enough to be present in early ICA-AtoM versions, but I admit I'm not sure. In any case, you can try running the following from AtoM's root installation directory:
- php symfony tools:get-version
Some notes on upgrading
You should be able to upgrade directly from an older ICA-AtoM version to the latest AtoM 2.x release, provided your current version is 1.1 or newer
If you are running a 1.0.x version, there will be some extra steps, which we have documented on our wiki, here:
However, if you installed in 2013 then my guess is you are running version 1.3.x, and you should be fine. In that case, you can follow our upgrading guide here:
Note that the upgrade process essentially involves installing a new version of AtoM alongside your old version, and then loading the data into the new installation and running a few upgrade and maintenance tasks. We've changed a number of dependencies since the older versions (for example, moving to Nginx instead of Apache for our webserver; moving to Elasticsearch as our search index, etc.) so make sure you read the installation docs carefully, and that installing new versions doesn't conflict with your older installation versions. For 2.5 we strongly recommend installing on Ubuntu 18.04 if possible, though 16.04 is also supported:
There's also an additional step to get the job-scheduler installed and configured - see:
The other thing that is required for the upgrade to go smoothly is that there is no data corruption in your database. Data corruption can occur when long running tasks (such as imports, move operations, large edits, etc) time out in the web browser before the operation has completed. This can sometimes leave partial rows in the database, which can then interfere with some of the database schema migration tasks from running successfully. In newer versions of AtoM we have moved many of the long running tasks to a job scheduler that can run asynchronously in the background (which avoids a lot of the timeout issues that used to occur in earlier versions), and we added support for transactions in MySQL (meaning that if an operation times out, the database will attempt to automatically roll back to the last known good state, to avoid leaving corrupted data). However, since this wasn't present in older versions, there is always a chance that when you get to the step of the upgrade process where you run the database upgrade task
, you run into issues.
If so, we have some suggestions on how to look for and troubleshoot these here:
Some of these suggestions may not work for very old versions of (ICA-)AtoM, but most should, since many of the core tables haven't changed.
Good luck, and let us know how it goes!