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 <al...@google.com> 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 <al...@google.com> 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 <rfern...@google.com> >> 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 <al...@google.com> 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 <lc...@google.com> wrote: >>>> >>>>> Charles, I would keep the process the same with respect to releasing. >>>>> >>>>> On Mon, Aug 13, 2018 at 11:00 AM Charles Chen <c...@google.com> 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 <al...@google.com> >>>>>> 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 >>>>>>> [2] https://github.com/apache/beam-site/pull/537 >>>>>>> >>>>>>> On Fri, Aug 10, 2018 at 5:20 PM, Lukasz Cwik <lc...@google.com> >>>>>>> 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 <al...@google.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Aug 10, 2018 at 12:33 PM, Lukasz Cwik <lc...@google.com> >>>>>>>>> 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 < >>>>>>>>>> pabl...@google.com> 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 <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 >>>>>>>>>>> <https://goto.google.com/pabloem-feedback> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>> >> > -- Got feedback? go/pabloem-feedback
