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]> 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]> 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]> 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]> >>> 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> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>> >>> >> -- > Got feedback? go/pabloem-feedback > <https://goto.google.com/pabloem-feedback> >
