The record of every version this server has run. Version History covers the two upgrade records, the live package and MongoDB readings, and what it means when the two records disagree.
What version history records
Version History is a log, not a control panel. Nothing on this page changes the server. It reports four facts about the Countly installation you are signed in to, and every one of them is read from the server itself rather than from anything a dashboard user typed.
Two of the four are live readings, taken the moment the page loads. Package version is the version of the Countly code currently running, read from the package the server was built from. MongoDB version is the version of the database server Countly is talking to, asked of the database directly.
The other two are histories. Each time an upgrade runs, it leaves a mark behind: the version it moved to, and the moment it finished. Countly keeps two of these marks side by side, one written by the half of the upgrade that replaces files and one written by the half that migrates data. The page shows them as two tables, oldest at the top, newest at the bottom, with a Current version pill on the newest entry when it matches the package running now.
An installation that has never been upgraded has short histories or none at all. That is normal and says nothing is wrong. The filesystem marks begin the first time an upgrade script runs. The database history can start earlier, because a container installation marks it when it is first installed.
Why an upgrade is two halves
A Countly upgrade is two jobs that run one after the other, and each one marks its own record when it finishes. That is the whole reason this page shows two tables instead of one.
The first half replaces code. New plugin files land on disk, dependencies are installed, the application is rebuilt. When that finishes, the new version is appended to the filesystem record, a file that lives on the server alongside the installation.
The second half migrates data. Collections are reshaped, indexes are added, documents are backfilled to whatever the new code expects to find. When that finishes, the new version is appended to the database record, which lives inside Countly's own database.
Because they are separate, they can end up out of step. A file upgrade that completed while the database scripts failed leaves the two records disagreeing, and that disagreement is the single most useful thing this page tells you. Countly notices it and raises a banner above the tables.
Each half also checks the record before it starts. An upgrade already marked as done is skipped rather than repeated, which is what makes it safe to re-run an upgrade after fixing whatever stopped it.
Use Cases
Confirm an upgrade finished
An upgrade has just run and you want to know whether both halves of it completed.
- Open Version History from the Manage menu.
- Read the bottom row of Filesystem version history. That is the newest mark the file upgrade left.
- Read the bottom row of Database version history and compare the two versions.
- Check that no amber banner sits above the tables. The banner appears only when the newest mark in each table disagrees.
- Confirm that Package version in the header matches what you upgraded to.
If the two tables disagree, the database half is the one that usually stopped, because it runs second. Re-running the upgrade is safe: each half checks its own record first and skips the work it has already marked as done.
Find when the server was last upgraded
Something changed in the product and you want to know when, so you can line it up against a change in your data.
- Open Version History.
- Look down the Upgraded / installed column of either table. Each row is one upgrade, in the order they happened.
- Read the timestamp on the bottom row for the most recent one, and the row above it for the one before that.
- Note the versions on both rows. The gap between them is what changed.
The two tables carry timestamps a few moments apart for the same upgrade, because the file half finishes before the database half starts. Either one is fine for dating a release. Use the database timestamp if you want the moment the upgrade was fully complete.
Report your version in a support ticket
You are opening a support ticket or filing a bug, and the first thing anyone will ask is what you are running.
- Open Version History.
- Copy Package version from the header. That is the Countly build in front of you.
- Copy MongoDB version from the header next to it.
- Copy the newest version from each table, and say whether the two agree.
- Include the date on that newest row, which tells support how long the installation has been on this version.
If a banner is showing, say so and quote both versions. A mismatch is usually the cause of the problem being reported rather than a separate issue.
Check the MongoDB version before an upgrade
A Countly release states a minimum MongoDB version and you need to know what you are actually running before you start.
- Open Version History.
- Read MongoDB version in the header. It is asked of the database server directly, so it reflects the server Countly is connected to right now, not what anyone configured.
- Compare it against the minimum in the release notes for the version you are moving to.
- Read Package version to confirm the release you are moving from.
This reading covers the database server Countly connects to and nothing else. On a replica set it reports the member serving this connection, so an upgrade in progress across members can be reported by the page before it is finished everywhere.
FAQs
Why are there two tables instead of one?
Because an upgrade is two jobs. One replaces the Countly files and one migrates the database, and each marks its own record when it finishes. Keeping them apart is what lets the page tell you that one of them did not complete.
A table shows a single row with no date. Is something broken?
Almost certainly not. A history with nothing recorded is shown as one row holding Package version, with a dash where the date would be. An installation that was set up at its current version and never upgraded can have nothing recorded, and a server whose files are not upgraded by the upgrade scripts has no filesystem marks at all. Package version and MongoDB version in the header still tell you what is running.
Why do the timestamps in the two tables differ for the same version?
The file half of an upgrade finishes before the data half begins, so the database mark is always a little later. A gap of seconds or minutes is expected. A gap of hours usually means the data half was started separately.
The banner says there is a mismatch. Can I clear it from here?
No. The banner is a comparison of the two records and it disappears when they agree again. Bringing them back into agreement is done on the server by completing the upgrade half that is behind.
Why does the newest row not show the Current version pill?
Because that pill requires the row's version to match Package version exactly. An upgrade run by the upgrade scripts marks the release series, so a mark of 26.01 against a package of 26.01.0 is the same release but not the same string. Compare the two by eye when the pill is missing.
Does this page tell me whether an upgrade is available?
No. It only reports what has already happened on this installation. Release announcements and upgrade instructions live outside the dashboard.
Can I see version history for one project?
No, and there is nothing to see. Countly is upgraded as a whole installation, so every project on this server runs the same version.