Ahmet, thank you for raising this topic, I think it defenitevly makes sense to have LTS releases, especially for enterprise users. The other potential solution could be patching only last 2-3 releases but, with a goal of 8 releases per year, it might cover quite a short time slice.
The only question for me - do we consider major release (3.0 will be the next one) as LTS release by default despite of the its number in release sequence? > On 15 Aug 2018, at 20:36, Pablo Estrada <[email protected]> wrote: > > No, I think that sounds good : ) > > On Wed, Aug 15, 2018 at 11:34 AM Ahmet Altay <[email protected] > <mailto:[email protected]>> wrote: > In the PR, I proposed starting with the next (2.7.0) release. I should have > made it more clear. One way of tracking would be having a table, or perhaps > adding this information to the downloads page. Do you have any ideas? > > > On Wed, Aug 15, 2018 at 11:28 AM, Pablo Estrada <[email protected] > <mailto:[email protected]>> wrote: > Thanks Ahmet for looking into this. I have a follow-up question. Have you > thought about the next few releases, and which one will be the first LTS > release? Also, how should we track this? > -P. > > On Wed, Aug 15, 2018 at 11:24 AM Ahmet Altay <[email protected] > <mailto:[email protected]>> wrote: > PR is reviewed and merged. Thank you all for the input. If you did not have a > chance to share your feedback, please propose any modifications that you > would like to see. I will be more than happy to make changes that would > allows us to serve our users better. > > On Tue, Aug 14, 2018 at 4:32 PM, Ahmet Altay <[email protected] > <mailto:[email protected]>> wrote: > Still waiting for any additional user feedback to come. I added reviewers to > the PR. Unless there is objections or additional feedback I would like to go > ahead with this version as it is. Modifications after that would always be > welcome. > > On Mon, Aug 13, 2018 at 2:06 PM, Rafael Fernandez <[email protected] > <mailto:[email protected]>> wrote: > I think this will great for the project! It's worked well for others (such as > Ubuntu). I like that this remains compatible with our desire to release every > six weeks, while keeping the support/patch load manageable. > > Release: +1 single process. This is just a statement of what we commit to > service. > > On Mon, Aug 13, 2018 at 12:31 PM Ahmet Altay <[email protected] > <mailto:[email protected]>> wrote: > I was not proposing any additional changes to the release process. If we > think that release process could be improved it would make sense to apply it > to all releases. > > On Mon, Aug 13, 2018 at 11:01 AM, Lukasz Cwik <[email protected] > <mailto:[email protected]>> wrote: > Charles, I would keep the process the same with respect to releasing. > > On Mon, Aug 13, 2018 at 11:00 AM Charles Chen <[email protected] > <mailto:[email protected]>> wrote: > (sending to the dev@ list thread as this is more relevant here than users@) > > Will we be using a different / potentially more rigorous process for > releasing LTS releases? Or do we feel that any validations that could > possibly be done should already be incorporated into each release? > > On Mon, Aug 13, 2018 at 10:57 AM Ahmet Altay <[email protected] > <mailto:[email protected]>> wrote: > Update: > > I sent out an email to user@ to collect their feedback [1]. I will encourage > everyone here to collect feedback from the other channels available to you. > To facilitate the discussion I drafted my proposal in a PR [2]. > > Ahmet > > [1] > https://lists.apache.org/thread.html/7d890d6ed221c722a95d9c773583450767b79ee0c0c78f48a56c7eba@%3Cuser.beam.apache.org%3E > > <https://lists.apache.org/thread.html/7d890d6ed221c722a95d9c773583450767b79ee0c0c78f48a56c7eba@%3Cuser.beam.apache.org%3E> > [2] https://github.com/apache/beam-site/pull/537 > <https://github.com/apache/beam-site/pull/537> > > On Fri, Aug 10, 2018 at 5:20 PM, Lukasz Cwik <[email protected] > <mailto:[email protected]>> wrote: > 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] > <mailto:[email protected]>> wrote: > > On Fri, Aug 10, 2018 at 12:33 PM, Lukasz Cwik <[email protected] > <mailto:[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/ <http://www.apache.org/security/> > > > > > On Fri, Aug 10, 2018 at 11:50 AM Pablo Estrada <[email protected] > <mailto:[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] > <mailto:[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> > > > > > -- > Got feedback? go/pabloem-feedback <https://goto.google.com/pabloem-feedback> > -- > Got feedback? go/pabloem-feedback
