[Prerequisite] Introduction to Semantic Version 2.0.0 notation.
DataMates Studio applicatons (dmsApp) leverage semantic version notation for build packaging, deployments and support tracking.
Using a Major.Minor.Patch.Early convention.
- With +1 Major version when backward compatibility breaks.
- Significant regression testing expected.
- Shift to version 1.0.0 for first official release.
- With +1 Minor version when new features are added.
- Might require end user training.
- Might require business process alignment updates.
- With +1 Patch version when applying fixes.
- Including security plugs and low impact improvements.
- Occassionally, an Early version for private, alpha, beta releases.
- Use ‘.n.{name}’ version as the 4th layer.
- Force an early release to be logically after a parent version.
- While remaining PHP version_compare() compatible.
- Enabling a ‘Version Support Maximum [GitLab]’ feature.
The plugin owner can clearly communicate what support level is available. Just pick one and follow it; during development workflow and releases.
- Level 00 – None. Published as-is without support.
- Level 01 – Current Major current Minor current Patch version.
- Aggressive update enforcement. Not user friendly.
- Level 02 – Current Major current Minor (*) Patch versions.
- Level 03 – Current Major prior Minor last Patch version.
- Level 04 – Current Major prior Minor (*) Patch versions.
- Level 05 – Current Major (*) Minor (*) Patch versions.
- Example: Official WordPress supported versions.
- Level 06 – Prior Major last Minor last Patch version.
- Level 07 – Prior Major last Minor (*) Patch versions.
- Level 08 – Prior Major prior Minor last Patch version.
- Level 09 – Prior Major prior Minor (*) Patch versions.
- Level 10 – Prior Major (*) Minor (*) Patch versions.
- … etc, etc, etc. There are plenty of combinations. Just pick one.
[Recommendation] Support offering is Level 05 for Current Major version, most of the time. With Level 07 for Prior Major Last Minor version, for a period of time after a new major release. Leveraging a ‘Version Support Minimum Soon [GitLab]’ WordPress administration area notice.
[Recommendation] No official support offering for Early versions; however, a feedback form and / or community forum will keep the communication lines open. Try to share all insights as soon as possible, to reduce unnecessary noise. Leveraging a ‘Version Support Maximum [GitLab]’ WordPress administration area notice.
[Flexability] At any time, a retrospective fix or security plug can be released for unsupported versions. A good example of a retrospective necro-patching can be found in the WordPress 3.7 release archive. Given that 8 years after WordPress 4.0 was released, you really should have upgraded away from WordPress 3.7.
- WordPress 3.7.0 (2013-10) released. Version 3 supported.
- WordPress 3.8.0 (2013-12) released. Version 3 supported.
- WordPress 3.9.0 (2014-04) released. Version 3 supported.
- WordPress 4.0.0 (2014-09) released. Version 4 supported.
- WordPress 5.0.0 (2018-12) released. Version 5 supported.
- WordPress 6.0.0 (2022-05) released. Version 6 supported.
- WordPress 3.7.41 (2022-11) patched. Version 6 supported.
Further Reading: WordPress PHP Statistics Journey to see semantic versioning in action and how it is used to track the growth of any application and its available features.