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