Thanks, I can see the reasoning for LTS releases based upon some enterprise customers needs.
Forgot about the 2.1.1 Python release. Thanks for pointing that out. On Fri, Aug 10, 2018 at 4:47 PM Ahmet Altay <[email protected]> wrote: > > On Fri, Aug 10, 2018 at 12:33 PM, Lukasz Cwik <[email protected]> wrote: > >> I like the ideas that your proposing but am wondering what value if any >> do supporting LTS releases add? We maintain semantic versioning and I would >> expect that most users would be using the latest released version if not >> the release just before that. There is likely a long tail of users who will >> use a specific version and are unlikely to ever upgrade. >> > > I believe there is a category of enterprise users who would continue to > use a specific version as long as they know they can get support for it. > This usually stems from the need to have a stable environment. There is > also the aspect of validating new product before using. I know some > companies have validation cycles longer than 6 weeks. They will still > upgrade but they would like to upgrade much less frequently. > > I was hoping that defining LTS releases will signal these types of users > what releases are worth upgrading to if they have a high cost of upgrading. > > This comes from my anecdotal evidence and I may be wrong. > > >> >> I believe it would be valuable to ask our users what is most important to >> them with respect to the policy (after we have discussed it a little bit) >> as well since ultimately our goal is to help our users. >> > > I agree with this. Since I am referring to enterprise users primarily I > think some of it will require the companies here to collect that feedback. > > >> This could then be documented and we could provide guidance to customers >> as to how to reach out to the group for big bugs. Also note that Apache has >> a security policy[1] in place which we should direct users to. >> > > I think document what could be expected of Beam in terms of support would > be very valuable by itself. It will also help us figure out what we could > drop. For example in the recent discussion to drop old API docs, there was > no clear guidance on which SDKs are still supported and should have their > API docs hosted. > > I think we reference to the Apache security policy on our website. If not > I agree, we should add a reference to it. > > >> >> Also, we don't have any experience in patching a release as we haven't >> yet done one patch version bump. All issues that have been brought up were >> always fixed in the next minor version bump. >> > > I agree. There was the Python 2.1.1 but that is the only example I could > remember. > > >> >> 1: http://www.apache.org/security/ >> >> >> >> >> On Fri, Aug 10, 2018 at 11:50 AM Pablo Estrada <[email protected]> >> wrote: >> >>> I think this all sounds reasonable, and I think it would be a good story >>> for our users. We don't have much experience with patching releases, but I >>> guess it's a matter of learning and improving over time. >>> -P. >>> >>> On Wed, Aug 8, 2018 at 9:04 PM Ahmet Altay <[email protected]> wrote: >>> >>>> Hi all, >>>> >>>> I would like us to clarify the life cycle of Beam releases a little bit >>>> more for our users. I think we increased the predictability significantly >>>> by agreeing to a release cadence and kudos to everyone on that. As a follow >>>> up to that I would like to address the following problem: >>>> >>>> It is unclear for a user of Beam how long an existing version will be >>>> supported. And if it will be supported at all, what does that support mean. >>>> (This is especially an important problem for users who would like to use >>>> stable versions and care less about being on the cutting edge.) >>>> >>>> Our current state is: >>>> >>>> - With our agreed release cadence Beam makes 8 releases a year. >>>> - We have precedence for patching released versions for major issues. >>>> - Patching all existing releases at any point (even patching a year >>>> full of 8 releases) will be significant work. >>>> >>>> With the problem and the information, I have the following proposal to >>>> define the life cycle of existing releases. >>>> >>>> - Define what is a major issue with Beam. (For example this could be >>>> high severity security issues and high risk data integrity issues.) >>>> - Have a concept of long term support (LTS) releases. Designate every >>>> 4th release as an LTS release (~6 months). >>>> - Deprecate non-LTS releases the moment any new Beam release is out. >>>> Never patch non-LTS releases. >>>> - Deprecate LTS releases after a new LTS release comes out. Patch any >>>> LTS release within 1 year of its initial release date. >>>> - Add the above information to our website. >>>> >>>> I think this proposal would give clear information to our users about >>>> what they can expect from us, and reduce our burden to maintain existing >>>> releases. >>>> >>>> I also would like to state my assumptions: >>>> >>>> - Releases will happen not because of a policy but because there are >>>> volunteers willing to do it. This proposal is only a framework for those >>>> volunteers to take action. If Beam does not support its releases, with or >>>> without a policy, we will reduce the trust of our users. >>>> - After we agreed to have a regular release cadence we started to see >>>> improvements towards having regular releases even though we did not >>>> perfectly hit 6 weeks mark each time. I do expect the same here: an >>>> improvement in the direction of user happiness even if we cannot be >>>> perfect. >>>> >>>> What do you think? >>>> >>>> Ahmet >>>> >>> -- >>> Got feedback? go/pabloem-feedback >>> <https://goto.google.com/pabloem-feedback> >>> >> >
