Skip to content

Release Lifecycle

Abstract

this chapter explains how long a release is supported and the associated rationale.

Types of releases

Each release is identified by three digits major.minor.patch

  • major identifies a major release number.
  • minor is increased whenever new features come in.
  • patch is 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.

Maintenance Policy

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.

Maintenance Table

The following table highlights the maintenance strategy. The release that re planned to be supported are highlighted in bold.

Important

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
7.0.0 2021-01-01 2023-01-01 9.0.0
6.1.0 2020-09-15 2022-03-01 8.0.0
6.0.0 2020-03-01 2021-03-01 deprecated
5.7.x 2019-11-22 2021-11-22 7.0.0
5.6.x 2019-10-11 2020-10-11
5.5.x 2019-08-09 2021-08-09 7.0.0
5.4.x 2019-07-21 2020-07-21 7.0.0
5.3.x 2019-06-04 2020-06-04 7.0.0
5.2.x 2019-05-20 2021-05-20 7.0.0
5.1.x 2018-11-22 2020-11-22 7.0.0
5.0.x 2018-06-01 2020-06-01 7.0.0

Important

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.