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> >>>>>> >>>>> >>>> >>
