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 <al...@google.com> 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
