Jmix Release Versioning

Release Versioning

Jmix release numbers follow a loose form of Semantic Versioning:

Versions are numbered in the form X.Y.Z, where:

  • X.0.0 is a major release, for example 1.0.0, 2.0.0
  • X.Y.0 is a minor release, for example 1.1.0, 2.3.0
  • X.Y.Z is a patch release, for example 1.0.1, 1.2.5
major
1
.
2
.
5
patch
minor
7
major
2
minor
4
patch

Major and minor releases introduce new features and are called feature releases.

Patch releases bring mostly bugfixes and fixes for important performance and security issues. Patch releases are 100% backwards compatible with the previous patch release. The only exception to this rule is when a security issue or data loss bug cannot be fixed without breaking backwards compatibility. If this happens, the release notes provide detailed instructions for upgrade.

Minor feature releases are mostly backwards compatible with the previous minor release. Exceptions to this rule are listed in the release notes as well as a way to address them. Usually, the required modifications in the source code and application configurations are applied automatically by Jmix Studio during a version upgrade.

Major feature releases may introduce incompatible changes in the Jmix architecture, API and functionality. However, Jmix Studio provides an automatic migration procedure to minimize the impact of changes in Jmix to application projects.

Deprecation Policy

A feature release may deprecate some features from previous releases. Deprecated features will continue to work in all minor releases of the same major version and may be removed in the next major release.

For example, if a feature is deprecated in Jmix 1.1, it will continue to work in 1.2, 1.3, 1.x, and will be removed in Jmix 2.0.

Release Cadence

Jmix uses a time-based release schedule, with feature releases every 4 months. Major versions are released at least once in 2 years. We recommend upgrading to each latest feature release if your project is in active development.

Latest minor releases of each major version are designated as long-term support (LTS) releases. For example: 5.0, 5.1 (LTS), 6.0, 6.1, 6.2 (LTS), 7.0. If your project is at the final stage of development or already shipped to production, you can stay on the latest LTS release to receive only critical updates.

Version Support Policy

At any given time, we support a set of feature releases to varying degrees.

The last feature release is in active support: it receives fixes for security issues, critical bugs, major functionality issues in new features of this release, regressions from older releases introduced in the current release.

Active support of non-LTS releases lasts 4 months until the next minor or major version is released. LTS releases are in active support for 8 months.

After the active support phase, a feature release moves to the maintenance phase. Maintenance means fixing critical security vulnerabilities and data loss bugs. Fixes are provided in a new patch release of the supported version.

Free maintenance is provided for 3 years for each LTS release and for 4 months for each non-LTS release.

Commercial maintenance is available for any feature release of Jmix, issued within 10 past years. This option could be useful for projects with a long lifecycle. You can learn more about the commercial maintenance service here.

If a critical security vulnerability or a data loss bug is caused by an external third-party dependency, we update the dependency if there is a newer fixed version. There may be cases when we may be unable to include the newer version of a dependency if architectural changes for that version prevent its usage in Jmix or the effort required to integrate the new version exceeds reasonable commercial efforts.

Extended Support for Version 1.x

According to the standard support policy explained above, release 1.5 (2023-02) should have been the last release of the 1.x version because the next release in the 4-month cycle is the major 2.0 (2023-06).

However, due to the incompatibility of UI technology between versions 1.x and 2.x, we will continue development of version 1.x in releases 1.6 and 1.7. The goal is to extend the free maintenance period for version 1.x to 5 years since 1.5 is released.

Release dates for 1.6 and 1.7 will not follow the 4-month cycle and will depend on the situation with accumulated changes.

Actual Support Schedule

Version
Release Date
End of Free Maintenance
End of Commercial Maintenance
1.3
2022-06
2022-10-30
2032-10-30
1.4
2022-10
2023-02-28
2033-02-28
1.5
2023-02
2024 Q1
2034 Q1
1.6 *
2024-07
2025 Q1
2035 Q1
1.7 LTS *
2025 Q1
2028-02-28
2038-02-28
2.0
2023-06
2023-10-30
2033-10-30
2.1
2023-10
2024-02-28
2034-02-28
2.2
2024-02
2024-06-30
2034-06-30
2.3
2024-06
2024-10-30
2034-10-30
2.4
2024-10
2025-02-28
2035-02-28
2+
Each 4 months
Non-LTS release - when next feature release is out. LTS release – in 3 years after release date.
In 10 years after release date
* - See Extended Support for Version 1.x