OpenFlower Version Update
OpenFlower Versioning Scheme
We try to respect as good as possible the Semantic Versioning for OpenFlower Versions
v2.4.1 for example, means:
Major Version "2". It changes when there are truly big updates that might break old features or add significant new ones. It comes when we introduce fundamentally new concepts inti the Software
Minor Version "4". It changes when new features are added in a way that doesn’t break existing ones. It should be possible to update the version and expect a working continuation of existing apps.
Patch Version "1". It changes when we do bug-fixes or improvements, that don't affect overall functionality.
We work with initiatives to add new functionality. This comes normally with the increase of the minor version. When we have a new bigger feature set ready, we introduce it as 2.4.0 for example. The Patch Version is "0". This updates should work in general, but we never can fully exclude not having introduced bugs or unexpected behaviour. Naturally we increase every day the tests and production quality and invest a lot of development time to keep also new features backward compatible.
It is suggested to test a new Minor Version with a Patch Version "0" separately as a Test-Installation. We do not suggest to update this simply on the existing older version.
After a new Minor Version we deliver typically the next patch version quite fast, considering all bugs, that we found or that was reported. The first and second Patch Versions we can count in typical cases as Stabe Versions.
OpenFlower SDK
The SDK has an independent versioning - yet still following the Semantic Versioning Scheme.
Since OpenFlower v2.4.0 we follow the principle, that the SDK will have the same Major and Minor Version as the Main OpenFlower Version - but it can have an independent Patch-Version.
External Component Plugins
Also external Component Plugins follow the Sematic Versioning Scheme with Major, Minor, and Patch versions. However, they are independent from the OpenFlower or OpenFlower SDK Versions.
Docker Images
The provided Docker Images from OpenFlower-Org follow the Sematic Versioning of OpenFlower. For every Release of the Codebase with a new Version, we also offer the pre-built Docker Containers for the All-in-one and Multi-Docker installation.
Next to the released Version Tags of OpenFlower there are 2 more tags with relevance:
/latest - These images contain typically a state of development which is somewhat stable - but not yet a released Patch Version. Critical Bugs, that we solved are fastest to get in the /latest tag. The /latest tag always based on the previous last published Patch Version.
/dev - these images can be seen like Nightly Builds. They contain evetually the latest stage of our development and are only for testing purposes.
Do not use a /dev tag image in production. These images are only to use in test installations aside.
Version Update
To update from an older to a newer version or OpenFlower, please follow this guide:
Please always make a Backup / Copy of your /lowcoder-stacks folder.
The magic behind an easy update is to make use of the /lowcoder-stacks mounted folder in the docker installations. That enables you to change the Versions of OpenFlower but not touch the Application Data. In the mounted /lowcoder-stacks folder, all MongoDB application data as also Logs and Assets are stored.
In other words, if you not use an external MongoDB Service, the OpenFlower MongoDB stores the Application Data of all your workspaces and Apps there, enabling you to exchange the docker without needing further backup and restore actions.
Based on the lowcoder-stacks folder, the data of a OpenFlower Installation can be transitioned without losses when you update to a new version of OpenFlower.
1) Stop your OpenFlower Docker Containers:
With Docker Compose
docker compose down
With pure Docker
Or in Docker Desktop
Stop and delete the "Container" you did run based on the old version.
2) Create a backup copy of the lowcoder-stacks Folder
Even if it should be never a problem, still we ask you kindly always to make a copy of the whole folder. Sometimes we have no other channce than to introduce breaking changes and we want to make sure you will never loss any data.
3) Download the latest OpenFlower Docker images.
With Docker Compose
With pure Docker
If you use Docker Desktop, you can pull the /latest tag or a specific version tag.
4) Adapt standard values to your Installation
For every Major Version, we likely introduce new ENV Variables. This is the reason to download the latest docker compose file. Naturally, you also can update your local copy with the new ENV Variables and other new config structures.
Edit the docker-compose file to your needs, but make sure to update only the settings. The following values must match your previous version to keep the OpenFlower MongoDB accessible for your stored Data Source Secrets.
LOWCODER_DB_ENCRYPTION_PASSWORD
LOWCODER_DB_ENCRYPTION_SALT
5) Run the new OpenFlower Docker-Image
After the image is pulled, you can run the image (create a new container) and configure directly the Ports as well as the ENV Variables.
Mind to re-connect (mount) the /lowcoder-stacks folder
With Docker Compose
docker compose up -d
Multi Image Docker Version handling
Technically, the Docker Versions and releases go "Hand in Hand". That means that you should always operate the same backend version of API-Service-Image & Node-Service-Image as the Frontend-Image. However, in special situations, the separation of these concerns into different images gives you a degree of freedom to update only one of the images and check the compatibility.
Last updated
