In short
Every published version is tagged in the repository, and that is where the exact list of changes lives. This page explains how to read a version number and what an upgrade implies — the detail of any given release staying at its source, where it cannot go stale.
Where to find the changes
Releases are published on the development repository, FramaGit, where each version carries a tag. The history attached gives the changes actually made, on the date they were made.
The images to deploy are published alongside, under the same number: the list of available versions can be consulted from the image registry.
Why this page does not copy the list out
A changelog copied by hand into documentation diverges from reality by the next release. A reliable pointer beats an out-of-date summary.
Reading a version number
Linkr follows the usual three-number convention — 2.4.1, for example.
| Position | What a change to it announces |
|---|---|
| Major | A fundamental change. Version 2 is a complete rewrite of Linkr, which was previously an R/Shiny application. |
| Minor | New features, without breakage. |
| Patch | Fixes. |
The images’ version, and the one the server answers with
The number that counts is the one on the images you deploy: it is what gets written into your archives and git repositories, and it is the one that must be identical on both images of a single installation.
Both images upgrade together
An installation whose two images carry different versions writes exports that disagree about their own format. See Production install.
Linkr also exposes a diagnostic address, /api/v1/health, used to check that the server responds. It returns a version number too — but not the images’ one, and it is not kept up to date with each release.
Do not use that address to confirm an upgrade
The number it returns is currently 2.0.0-dev, whatever version is deployed. After an upgrade, check the image tags in your deployment file rather than this response.
What an upgrade implies
Migrations apply by themselves
No command to run: the schema is brought up to date on start, and does nothing when it already is.
Rolling back is not symmetrical
Those migrations do not replay backwards: returning to the previous image is not enough. The backup taken before the upgrade is the real rollback.
Your exports stay readable
An archive produced by an earlier version re-imports: older file shapes are tolerated on reading.
Reporting a problem, suggesting an improvement
Bugs and requests go on the repository. A useful report carries the version deployed, the mode — browser or server —, and what you expected against what happened.
Going further
- Production install — the procedure for upgrading.
- Backup and restore — to do before any upgrade.
- Glossary — the terms used in this documentation.