Motivation

As Flink heads towards its release 2.0, which includes significant API changes and deprecations, it’s important to support smooth migration for the users of the 1.x version. Providing a stable and supported 1.x version for an extended period of time will help users prepare and adopt to the changes in 2.0. This FLIP outlines our plan to support the last release of Flink 1.x and aims to provide clarity for the community as they get ready to switch to Flink 2.0.

Proposed Changes

• What LTS means for 1.x:
  • The last 1.x release will be designated as a Long-Term Support (LTS) version.
  • This LTS version will only get bug fixes and important updates but no new features in order to keep it stable and reduce the work needed to maintain it.

• Support duration:
  • Time-based support with a set end date of 2 years. This gives a clear deadline, which helps motivate users to plan their upgrade.

Public Interfaces

• No new APIs will be added. We’ll focus on keeping the current APIs working well and ensuring they stay compatible until the end of the LTS period.

Compatibility, Deprecation, and Migration Plan

• We’ll provide a detailed guide to help users move from 1.x to 2.x, focusing on the changes to old APIs and new features in 2.x.
• The LTS release should contain all major deprecation hints important for migration to 2.x.
• We'll update the website and documentation to include the explanation of the LTS policy and publish it before or upon the release of the final version of the 1.x line. The following text is proposed:
  

Long-Term Support (LTS) Policy:

Since major versions typically introduce breaking changes, the final minor release of each major version line is designated as a Long-Term Support (LTS) version. Supported for a fixed period of two years with only bug fixes and security updates, these LTS versions provide a stable and predictable timeframe for preparing and transitioning to the next major Apache Flink release.

Test Plan

• Continued support for existing test suites to ensure no regressions in the LTS version.

Rejected Alternatives

Support duration:

• Option 2: Release-based support where the LTS version is supported until there are four more minor releases in the 2.x line, likely around 2 years. This, somewhat unnecessarily, links the support length to how quickly new 2.x versions are released.
• Option 3: Support from one LTS to the next LTS in 2.x. This  doesn’t encourage users to upgrade and might leave them unprepared for major version changes.

Backporting new features to 1.x:

• We decided against this because it might keep users from moving to the newer 2.0 version and make it harder for us to maintain.