DGT-OmegaT: new numerotation scheme

What does not change: left part

First two numbers keep the original meaning:

• First number is fork number:
  • DGT-OmegaT 1.x was based on OmegaT 2.6,
  • DGT-OmegaT 2.x was based on OmegaT 3.1,
  • DGT-OmegaT 3.x is based on OmegaT 3.6
  • An eventual branch 4.x would be based on OmegaT 4.3 or 5.2, if we begin this development one day.
• Second number is branch number. It changes when one branch goes to production:
  • previously we had 3.2 in production, 3.3 in test and 3.4 in dev;
  • now we have 3.3 in production, 3.4 in test and 3.5 in dev;
  • later we would have 3.4 in production, 3.5 in test and 3.6 in dev;
  • etc.

Why we change

Until 2017, and simultaneously, until DGT-OmegaT was published on internet, changes were asked frequently by DGT users, and the test period was very short. That means that changes in the second number were very frequent and there was not a big gap between production and test branch. Now this is the contrary, there can be months, if not years, between the start of a development branch and the moment it is put in production. That is the reason why branches 3.0 and 3.2 had more than 20 updates.

A first problem came with branch 3.1 after it was put in production: some changes were made available in the public version (the one you can download in this website) long time before it was put in production internally inside DGT. And the contrary was also true: some changes considered as urgent inside DGT could not be published immediately in the website. The consequence was that we had, indeed, two 3.1 branches, one internal and one public.

Another problem came with branch 3.3 containing the feature new score: this feature was finally removed from branch 3.3 in production because it is considered as not mature enough, while other features needed to be put in production right now. The consequence is that what is in production is not directly based on 3.3 update 5, but more on 3.3 update 1 with some parts from update 5, but without changes from updates 2 and 3.

New scheme for right part

The first thing which changes is that update in the version number definitively disappears, independently from the branch: releases will be numbered as PROD-1 instead of PROD update 1, TEST-5 instead of TEST update 5.

The status (PROD, DEV, TEST) is now a part of the numerotation, which is not anymore linear: if TEST-7 goes finally to production, it is renamed as PROD-1 (first release in production), not PROD update 8. This is because some features from TEST-7 may  have been removed, as it occured for the new score, meaning that PROD-1 can for example contain features from TEST-4, TEST-6, and TEST-7 while features from TEST-5 have been removed. Such an information will then be present in the announcement of the concerned version and in the file release/changes.txt.

To avoid the problem we had with release 3.1, now the word PROD is strictly reserved for the internal version, which is not published. The version for daily use which can be downloaded on the web site is named STABLE. Actually you can download 3.3-STABLE-1. This is, indeed, actually identical to internal 3.3-PROD-1 but it may differ in next version, without any publication about it on the website.

Possible statuses are DEV, TEST, RC (externally: frozen version, a release candidate, i.e. a version which will only receive corrections of bugs or documentation, but is not yet ready for production), ACC (acceptance, can be either the RC version or a correction to last PROD which must be tested), STABLE (external), PROD (internal). In case you absolutely want a version number made only from digits, which enables easier sorting, then you can consider that 3.3-DEV-1 = 3.3.0.1, 3.3-TEST-1 = 3.3.1.1, 3.3-RC-1 = 3.3.6.1, 3.3-ACC-1 = 3.3.7.1, 3.3-STABLE-1 = 3.3.8.1 and 3.3-PROD-1 = 3.3.9.1

Normally, PROD and STABLE versions should have only one digit after the status, because they are supposed to receive only corrections of bugs.

On the contrary, DEV and TEST versions will now use 2 subversion digits:

• the first one is incremented when we add an important feature, implying lot of changes and which may be removed if it finally does not work
  • either because it implies lot of tests and we are not sure to finish them before putting other features in production
  • or because it concerns multiple parts of OmegaT code and a bug would necessarily have a big impact to the whole stability of the application
• the second one is incremented
  • if we add only minor features (if there is a bug inside it will not corrupt the full application),
  • if we only correct bugs, or
  • if it is a continuation of the feature implemented when we started this sub-branch (i.e. when we incremented the major number last time)

Since most published versions contain multiple changes, most often we will have a mix between all these conditions, in which case the major change have priority on minor ones. The goal is to have a possibility to reflect rollback of a major change in the numerotation. Imagine that after release 3.5, we publish a major change with number 4.0, and some bugfixes. But finally this major change does not work and we have to rollback but keep the bugfixes: thanks to new numerotation, next release will be 3.6 because this number was left free just in case. With 1-level linear numerotation, this is not possible to reflect such a rollback.

To illustrate this last point, let's see what happens with branch 3.3 when it was in TEST:

Now in the file changes.txt, all releases for branches 3.0 to 3.2 will display for info only what should have been the version number, if we had adopted this numerotation earlier. For branches 3.3 and 3.4, we do the contrary, putting the old numerotation in comment. And from 3.3-PROD-1, 3.4-TEST-1 and 3.5-DEV-1, we only display the new numerotation.

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.