Strategies for Releasing New Versions
Our company prefers to release new versions (with fewer changes) at more frequent intervals instead of releasing just a few “large” versions per year. This allows us to deliver the required functionalities to our customers faster than we would be able to in the other way.
The rapid release of new versions is, of course, conditional on quality testing, including the consistent use of automated tests.
The Next Minor Version Release
3.11.2020 - version 7.6.1
17.11.2020 - version 7.6.2
1.1.2021 - version 7.7.0
Our company uses a four-part version number, for example 126.96.36.199, where:
- 7 (Major) – major changes to the application (or transition to another technology) or implementation of significant functionalities. In this particular case, seven means the transition to .NET technology.
- 3 (Minor) – it is changed when the implementation of the functionality package is completed and thus stands more for the development series.
- 1 (Patch) – it is changed during the implementation of each minor functionality or bug fix.
- 18 (Build) – only for bug fixes and various “hotfixes”.
The second number (minor) serves as a designation of a package of planned changes. As soon as the previous functionality package is developed and released (for example, 7.3.x), the minor version is raised to 7.4.0 and new functionalities that are included in version 7.4.x are gradually implemented (and released). Once this whole package is (gradually) developed and deployed, the minor version is raised again and the implementation of another package begins.
List of Functionalities Included in Future Implementation
There is a brief description in each change and an anticipated minor version in which the functionality should be developed and deployed – but this may change over time as our customers' priorities evolve.
Only major changes are listed; minor features and improvements are not listed.