DGT-OmegaT: numerotation scheme, bis

With release 3.3 of DGT-OmegaT we introduced a new numerotation scheme, to reflect the complexity of our development plans. We will continue to use it, but we introduced some improvements.

Test and Beta

Last time we explained that we made a strict distinction between PROD branch name, which is now strictly restricted to internal release, and STABLE which is published in the web site. The reason was that it had occured in the past, and may occur again, that what is published in the web site differs from the internal production environment. Indeed, PROD and STABLE branches were identical until 3.3-STABLE-3/PROD-3, then STABLE-4 corrected a situation which has zero chance to occur internally, while in production we started a new deployment plan to introduce some features from the TEST release.

Now it appears that the same cause will also apply to the TEST environment: the internal environment will not contain the same thing as what is in to-be-tested branch on the web site. So, we have to make the same distinction.

From now the intermediate branch (i.e. the one which is in the middle of the download page) will be referred as BETA, not anymore as TEST: the term TEST is strictly reserved to internal environment.

In the release declaration (in the file release/changes.txt) you will see in real time whenever BETA and TEST are identical or not. But as for production, what is in TEST is never public: it may contain features not to be published.

Distribution-only changes

All what is described in previous sections is registered in a properties file inside the source code, which will then go to OmegaT.jar ; as a consequence, it changes only if the source code changes.

There are a few situations where change appear in the binary version ("without JRE") while implying no change in the source: when a change implies only a plugin, the segmentation, the configuration... However, if it corrects a bug, this can be published in emergency and we do not want to publish a new release of the source code only to change the version number. On the other hand, we need to make the change visible, so that if people complain about the bug, we can ask them to check if they downloaded the update or not.

In such a case we will add also a release tag after the mentioned number: for this we use latin notation -bis, -ter, -quarter, -quinquies... Hope we won't need to use more than that.

So, if the version you just downloaded is named, for example, 3.5-DEV-5.0-bis, that means that something has changed in binary archive (for example, the segmentation rules, the documentation, etc) but the source version is still 3.5-DEV-5.0

Such a tag is not in the source code nor in the jar file: it is in the file changes.txt only. In this file you can also learn about what has changed exactly.