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]> 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]> 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]> 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]> 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]> 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 <[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]> wrote: >>>>>> >>>>>>> >>>>>>> On Fri, Aug 10, 2018 at 12:33 PM, Lukasz Cwik <[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/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>
