this chapter explains how long a release is supported and the associated rationale.
Types of releases¶
Each release is identified by three digits
majoridentifies a major release number.
minoris increased whenever new features come in.
patchis increased whenever a fix is delivered, resolving a reported and identified bug.
Major versions, such as 4.x.y, 5.x.y 6.x.y bring in major new features and cots upgrades. Backward compatibility is not guaranteed. Any compatibility change is documented in the migration guide.
Minor versions, such as 6.1.x and 6.2.x are meant to introduce new features while not breaking compatibility. This said, upgrading to a minor to the next one may incur minor changes in some configurations. These are fully documented in each migration guide.
Maintenance releases, such as 6.1.1 and 6.1.2, only bring in bug fixes.
In general, Punch minor releases have a minimum support period of 1 year and a maximum of 2 years. When a new major release is published, the major - 2 release is end-of-life. I.e. no more than two major punch releases are supported at any time.
The following table highlights the maintenance strategy. The release that re planned to be supported are highlighted in bold.
What this says is that if you run a (say) 5.3.0 we strongly encourage you to upgrade to at minimum a 5.5, most likely to a 5.7.x. The Punch team is there to help you evaluate the migration impact.
|Release||Release date||End-Of-Life||Maintained until|
You may wonder : why is the (say) 5.3.x or 5.6.x not supported as long as 5.5 or 5.7. The reason is a win-win strategy to limit the number of supported release branches while keeping a steady rythm of delivering new important features. Many customers use a release for a long build or evaluation process. This process takes sometimes months (or years). It is likely they have the opportunity during this time period to require or test some new features. What is important at the end is to clearly identify which target release will be the production one.