On Thu, Aug 16, 2018 at 7:56 PM Ahmet Altay <[email protected]> wrote: > > Thank you Alexey, Robert for the feedback! > > On Thu, Aug 16, 2018 at 5:26 AM, Robert Bradshaw <[email protected]> wrote: >> >> I think this is a worthwhile thing to do. I would just have one change: I >> think that rather than deciding each Nth release is an LTS, we should do so >> at the time of the release based on the time since the last LTS, the number >> of LTS releases currently in flight, and whether the accumulated feature set >> from the last LTS provides significant value to upgrade. (One risk I'd like >> to avoid is having LTS releases become dragged out by people trying to get >> stuff in). > > > I agree with this assessment and the risk. I proposed every Nth as a way to > keep LTS releases coming out. I was concerned about not making any LTS > releases for a long time.
Yeah. We could certainly have every Nth release by default to keep the cadence up, but note that it's very flexible. Your wording below sounds fine to me. > How about something like: > > "The community will mark some releases LTS releases (based on the factors > such as the number of LTS releases currently in flight, and whether the > accumulated feature set from the last LTS provides significant value to > upgrade). There will be at least one new LTS release in a 12 month period." > > I prepared a PR draft for the above change > (https://github.com/apache/beam-site/pull/539). I will be OOO for a few > weeks, feel free to edit/merge my PR. I can also do this when I am back. > >> >> >> Generally, x.0.0 releases are not used by the target audiences of LTS >> releases, so I would not plan on it (by default at least) becoming an LTS >> candidate. > > > I agree with Robert. We can let the community decide based on how we feel at > that time, but unlikely in my opinion. > >> >> >> >> On Thursday, August 16, 2018, Alexey Romanenko <[email protected]> >> wrote: >>> >>> 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]> 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]> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> -- >>>>> Got feedback? go/pabloem-feedback >>>> >>>> >>> -- >>> Got feedback? go/pabloem-feedback >>> >>> >
