Hi, I'd like to return to the discussion around a long term support release that first came up here in 2018:
https://lists.apache.org/thread.html/6ec572d8edfe93225edebec18792cbcf44ef447ffe54ea35549cdafe%40%3Cdev.beam.apache.org%3E This is important to some Google Cloud Dataflow Java customers, and likely others as well. Specifically, I'd like to propose cutting an LTS release off a branch and maintaining it with critical bug fixes and security updates for 18 months. Right now we're finding that the current one year support period and six week release cycle is a tad fast for some customers. There's some wiggle room in terms of what's "critical", but in that category I include security fixes and data integrity issues. Essentially, this is any bug so bad that, if found in a new release, we'd recommend customers wait for the fix before upgrading to the latest and greatest. The difference is we'd backport the patch to the not-latest-and-greatest release. To run something up the flagpole, I propose: 1. 2.28.0 becomes the first LTS release. 2. New patch versions are released as 2.28.1, 2.28.2, etc. 3. Patch releases do not change API, at all, except in the unlikely event this is absolutely required for a security fix. 4. Dependencies are not upgraded in patch releases unless required to fix a critical bug or security issue. 5. In a year, cut a new LTS release from whatever is then current so there's some overlap to give customers time to switch over. I picked 2.28.0 since it's the most recent release, and I prefer to stay off the bleeding edge for longterm support. This would also enable customers to develop on top of it sooner. However I understand others may well prefer to pick a different release such as 2.29.0 or 2.30.0. I'm OK with whatever recent version the community picks. Thoughts? -- Elliotte Rusty Harold [email protected]
