Zorp Gateway
Related pages
Version policy
The question of software upgrades is one of the most important and most problematic areas of an IT system. We would like to help you in this regard the best possible way by providing information about our release cycles and version numbering practices.
Product branches
Every stable branch is identified by a two digit version number which refers to every release of the branch (for example, Zorp 3.1 refers to the whole 3.1.x series and includes several releases).
A branch starts with the main release (for example, 3.1.1); further releases (3.1.2, etc.) of the branch usually include only minor changes and bugfixes, fixing possible problems. No major changes take place within the branch.
You can download these in-branch updates free of charge, no software subscription is necessary.
Version numbers of applications
Stable releases
We publish stable updates to our products at about every two months. Stable releases are identified by three digit version numbers (like 3.1.7). Use the latest stable release available in the branch.
The upgrade page of our website contains the latest version of the supported branches, including the release date and release notes.
Update releases
Update releases are releases that include only a few (usually one or two) important bugfixes compared to the latest stable release. Update releases are stable releases that we make available before releasing the next stable version. Update releases are marked by an extra letter after the three digit version number: for example, an update release for release 3.1.7 would be labeled as 3.1.7a. If an update release is published, it is recommended to use it instead of the latest stable release.
Test releases
Before publishing a "stable" version we start a BETA session and publish one or more test releases. Test releases can be identified by their version number: stable releases have 3 digit version numbers, while test releases have 4 digit version numbers (for example, 3.1.4.1). Though these releases might not be perfectly stable, it might be possible that certain bug fixes are only available in test releases. Your help and feedback about these test releases is greatly appreciated.
Test releases are run through our regression-testing framework to ensure that no major functionality problems remain. You may want to use test releases when you experience a problem that is fixed in the test release, but no stable version containing the same fix is available. To use test releases you need to fetch upgrades from our "test" branches by modifying your /etc/apt/sources.list file. For example to use test releases for 3.1 you have to add the following line to your apt sources file:
deb http://apt.balabit.hu/zorp-os zorp-os-3.1/3.1test common common-gpl zms-agent zorp zas zms zorp-os zorp-os-extra
Snapshot releases
Snapshots are created during the preparations to test releases, they are used as input to our internal test system. It is easy to recognize test releases as they contain a date stamp in their version number, for example:
zorp-pro-2.1.5+20040121+1855_i386.deb
Version numbers of shared components
The previous sections contained information about our applications, but our products include shared components (shared libraries or DLLs) that several applications may use. The version numbers of shared components differ from the version numbers of applications as they contain one more digit. For example, a stable release of the libzorpll library is "2.1.12.3"; the first test version of this library would be identified by "2.1.12.3.1".
The first three digits of version number represent binary compatibility, for example a program depending on 2.1.12.1 will run with version 2.1.12.3, but this is not true in the other direction, a program depending on 2.1.12.3 will not run with anything below 2.1.12.3.
We try to keep binary compatibility in a stable branch, but in some rare cases when this is not possible all shared components and applications must be upgraded at the same time on a single host.
When a binary incompatible version is released the first three digits change in the version number and the fourth becomes 0. For example if an incompatible release is made after 2.1.12.3 it becomes 2.1.13.0.
