Menu
▾
▴
#1440 Change versioning scheme
The existing OmegaT version scheme includes an "update" number that has the following problems:
- It has too many degrees of freedom: it allows making very fine distinctions that users don't care about, and that are hard to judge for developers
- It's inconveniently different from commonly used version schemes in the wild, specifically semver. In addition to being unfamiliar, for instance this makes distribution as a Maven artifact unwieldy.
- It's inconsistent in that it requires a bunch of special handling around "update": when zero, omit from version strings. This makes packaging for package managers inconvenient.
Starting with OmegaT 4.2.0, the versioning scheme will be as follows:
OmegaT versions loosely follow semver (https://semver.org/). The version number consists of three parts: MAJOR.MINOR.PATCH. When PATCH is zero it can be elided from documentation or casual references, but not in code.
- MAJOR: The distinction between "standard" (sometimes "beta" in the code) and "latest"
- MINOR: "Large" changes that affect the UI or core functionality
- PATCH: Bug fixes and small changes that aren't "large"
In the past there was also an "update" number following PATCH, but this has been deprecated.
For consistency's sake, would it be worth it to apply this version scheme to the current stable and release a 3.6.1 ?
3.6 is officially EOL, and I definitely wouldn't release a new version with no other changes just to switch the versioning scheme.
Since you are already touching versioning and build system could you fix the InnoSetup installer script to NOT use version number in the "AppName" directive as it's explicitly forbidden in the InnoSetup documentation and causes the installer not to detect previous installations (intentionally or not) as it is used as "AppId" in the absence of an actuall "AppId" directive?
That sounds like something worth looking into, but
Released in version 4.2.0.