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?