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 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. 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. 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. 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> >
