msg Project Server follows a rolling release strategy. This means that no regular releases are made. Instead every change to the Project Server packages creates a new Project Server version.

Therefore a Project Server version is identified by a 

• major version number
• minor version number
• date

Example: "4.0.20200324".

For some this may sound intimidating because they maybe afraid that incompatible changes will spoil their setup during an upgrade. But this is not the case. Updates within the same major and minor version number (e.g. "4.0") will only incorporate additions and bug fixes. If in exceptional cases a small incompatible change is introduced it will be documented as such and will not be a "breaking change". It will never put a threat to the overall function of Project Server.

Increasing the minor version number (e.g. going from "4.0" to "4.1.") may bring changes which break backward compatibility. Such an upgrade will therefore never happen silently through a simple psa upgrade but will always be announced together with proper migration instructions.

We chose rolling release because it is almost impossible to prevent that updates of low level components happen, e.g. for the Docker engine (which you really should have at their most recent public release version) or fixes to OS components. Put shprt, what you can expect from Project Server rolling releases the is same what you expect when doing a simple apt update && apt upgrade on the Debian OS level: Added features and removed bugs - but it will not fail to work or exhibit a considerably different behaviour.

Please note that we are referring here to Project Server's own version history comprised by all the Debian packages which as a whole constitute the Project Server environment. (You can list them by running dpkg-query -l 'ps-*'.) Each stack lives in its own version history, dominated by the downstream updates of the appliation which is at the core of this stack. To list installed and current stack versions use docker-stack status.