There seems to have been lack of demand. I agree we should remove these statements from our site until we find a reason to re-visit doing LTS release.
On Tue, Mar 24, 2020 at 2:23 PM Austin Bennett <whatwouldausti...@gmail.com> wrote: > > What's our LTS policy these days? It seems we should remove the following > from our site (and encourage GCP does the same, below), if we're not going to > maintain these. I'll update policy page via PR, if get the go ahead that it > is our desire. Seems we can't suggest policies in a policy doc that we don't > follow...? > > I am not trying to suggest demand for LTS. If others haven't spoken up, that > also indicates lack of demand. Point of my message is to say, we should > update our Policies doc, if those aren't what we are practicing (and can > re-add later if wanting to revive LTS). > > https://beam.apache.org/community/policies/ > > Apache Beam aims to make 8 releases in a 12 month period. To accommodate > users with longer upgrade cycles, some of these releases will be tagged as > long term support (LTS) releases. LTS releases receive patches to fix major > issues for 12 months, starting from the release’s initial release date. There > will be at least one new LTS release in a 12 month period, and LTS releases > are considered deprecated after 12 months. The community will mark a release > as a LTS release based on various factors, such as the number of LTS releases > currently in flight and whether the accumulated feature set since the last > LTS provides significant upgrade value. Non-LTS releases do not receive > patches and are considered deprecated immediately after the next following > minor release. We encourage you to update early and often; do not wait until > the deprecation date of the version you are using. > > > > > Seems a Google Specific Concern, but related to the community: > https://cloud.google.com/dataflow/docs/support/sdk-version-support-status#apache-beam-sdks-2x > > Apache Beam is an open source, community-led project. Google is part of the > community, but we do not own the project or control the release process. We > might open bugs or submit patches to the Apache Beam codebase on behalf of > Dataflow customers, but we cannot create hotfixes or official releases of > Apache Beam on demand. > > However, the Apache Beam community designates specific releases as long term > support (LTS) releases. LTS releases receive patches to fix major issues for > a designated period of time. See the Apache Beam policies page for more > details about release policies. > > > > > > > > > > On Thu, Sep 19, 2019 at 5:01 PM Ahmet Altay <al...@google.com> wrote: >> >> I agree with retiring 2.7 as the LTS family. Based on my experience with >> users 2.7 does not have a particularly high adoption and as pointed out has >> known critical issues. Declaring another LTS pending demand sounds >> reasonable but how are we going to gauge this demand? >> >> +Yifan Zou +Alan Myrvold on the tooling question as well. Unless we address >> the tooling problem it seems difficult to feasibly maintain LTS versions >> over time. >> >> On Thu, Sep 19, 2019 at 3:45 PM Austin Bennett <whatwouldausti...@gmail.com> >> wrote: >>> >>> To be clear, I was picking on - or reminding us of - the promise: I don't >>> have a strong personal need/desire (at least currently) for LTS to exist. >>> Though, worth ensuring we live up to what we keep on the website. And, >>> without an active LTS, probably something we should take off the site? >>> >>> On Thu, Sep 19, 2019 at 1:33 PM Pablo Estrada <pabl...@google.com> wrote: >>>> >>>> +Łukasz Gajowy had at some point thought of setting up jenkins jobs >>>> without coupling them to the state of the repo during the last Seed Job. >>>> It may be that that improvement can help test older LTS-type releases? >>>> >>>> On Thu, Sep 19, 2019 at 1:11 PM Robert Bradshaw <rober...@google.com> >>>> wrote: >>>>> >>>>> In many ways the 2.7 LTS was trying to flesh out the process. I think >>>>> we learned some valuable lessons. It would have been good to push out >>>>> something (even if it didn't have everything we wanted) but that is >>>>> unlikely to be worth pursuing now (and 2.7 should probably be retired >>>>> as LTS and no longer recommended). >>>>> >>>>> I agree that it does not seem there is strong demand for an LTS at >>>>> this point. I would propose that we keep 2.16, etc. as potential >>>>> candidates, but only declare one as LTS pending demand. The question >>>>> of how to keep our tooling stable (or backwards/forwards compatible) >>>>> is a good one, especially as we move to drop Python 2.7 in 2020 (which >>>>> could itself be a driver for an LTS). >>>>> >>>>> On Thu, Sep 19, 2019 at 12:27 PM Kenneth Knowles <k...@apache.org> wrote: >>>>> > >>>>> > Yes, I pretty much dropped 2.7.1 release process due to lack of >>>>> > interest. >>>>> > >>>>> > There are known problems so that I cannot recommend anyone to use >>>>> > 2.7.0, yet 2.7 it is the current LTS family. So my work on 2.7.1 was >>>>> > philosophical. I did not like the fact that we had a designated LTS >>>>> > family with no usable releases. >>>>> > >>>>> > But many backports were proposed to block 2.7.1 and took a very long >>>>> > time to get contirbutors to implement the backports. I ended up doing >>>>> > many of them just to move it along. This indicates a lack of interest >>>>> > to me. The problem is that we cannot really use a strict cut off date >>>>> > as a way to ensure people do the important things and skip the >>>>> > unimportant things, because we do know that the issues are critical. >>>>> > >>>>> > And, yes, the fact that Jenkins jobs are separately evolving but pretty >>>>> > tightly coupled to the repo contents is a serious problem that I wish >>>>> > we had fixed. So verification of each PR was manual. >>>>> > >>>>> > Altogether, I still think LTS is valuable to have as a promise to users >>>>> > that we will backport critical fixes. I would like to keep that promise >>>>> > and continue to try. Things that are rapidly changing (which something >>>>> > always will be) just won't have fixes backported, and that seems OK. >>>>> > >>>>> > Kenn >>>>> > >>>>> > On Thu, Sep 19, 2019 at 10:59 AM Maximilian Michels <m...@apache.org> >>>>> > wrote: >>>>> >> >>>>> >> An LTS only makes sense if we end up patching the LTS, which so far we >>>>> >> have never done. There has been work done in backporting fixes, see >>>>> >> https://github.com/apache/beam/commits/release-2.7.1 but the effort was >>>>> >> never completed. The main reason I believe were complications with >>>>> >> running the evolved release scripts against old Beam versions. >>>>> >> >>>>> >> Now that the portability layer keeps maturing, it makes me optimistic >>>>> >> that we might have a maintained LTS in the future. >>>>> >> >>>>> >> -Max >>>>> >> >>>>> >> On 19.09.19 08:40, Ismaël Mejía wrote: >>>>> >> > The fact that end users never asked AFAIK in the ML for an LTS and >>>>> >> > for >>>>> >> > a subsequent minor release of the existing LTS shows IMO the low >>>>> >> > interest on having a LTS. >>>>> >> > >>>>> >> > We still are heavily iterating in many areas (portability/schema) and >>>>> >> > I am not sure users (and in particular users of open source runners) >>>>> >> > get a big benefit of relying on an old version. Maybe this is the >>>>> >> > moment to reconsider if having a LTS does even make sense given (1) >>>>> >> > that our end user facing APIs are 'mostly' stable (even if many still >>>>> >> > called @Experimental). (2) that users get mostly improvements on >>>>> >> > runners translation and newer APIs with a low cost just by updating >>>>> >> > the version number, and (3) that in case of any regression in an >>>>> >> > intermediary release we still can do a minor release even if we have >>>>> >> > not yet done so, let's not forget that the only thing we need to do >>>>> >> > this is enough interest to do the release from the maintainers. >>>>> >> > >>>>> >> > >>>>> >> > On Tue, Sep 17, 2019 at 12:00 AM Valentyn Tymofieiev >>>>> >> > <valen...@google.com> wrote: >>>>> >> >> >>>>> >> >> I support nominating 2.16.0 as LTS release since in has robust >>>>> >> >> Python 3 support compared with prior releases, and also for reasons >>>>> >> >> of pending Python 2 deprecation. This has been discussed before >>>>> >> >> [1]. As Robert pointed out in that thread, LTS nomination in Beam >>>>> >> >> is currently retroactive. If we keep the retroactive policy, the >>>>> >> >> question is how long we should wait for a release to be considered >>>>> >> >> "safe" for nomination. Looks like in case of 2.7.0 we waited a >>>>> >> >> month, see [2,3]. >>>>> >> >> >>>>> >> >> Thanks, >>>>> >> >> Valentyn >>>>> >> >> >>>>> >> >> [1] >>>>> >> >> https://lists.apache.org/thread.html/eba6caa58ea79a7ecbc8560d1c680a366b44c531d96ce5c699d41535@%3Cdev.beam.apache.org%3E >>>>> >> >> [2] https://beam.apache.org/blog/2018/10/03/beam-2.7.0.html >>>>> >> >> [3] >>>>> >> >> https://lists.apache.org/thread.html/896cbc9fef2e60f19b466d6b1e12ce1aeda49ce5065a0b1156233f01@%3Cdev.beam.apache.org%3E >>>>> >> >> >>>>> >> >> On Mon, Sep 16, 2019 at 2:46 PM Austin Bennett >>>>> >> >> <whatwouldausti...@gmail.com> wrote: >>>>> >> >>> >>>>> >> >>> Hi All, >>>>> >> >>> >>>>> >> >>> According to our policies page [1]: "There will be at least one >>>>> >> >>> new LTS release in a 12 month period, and LTS releases are >>>>> >> >>> considered deprecated after 12 months" >>>>> >> >>> >>>>> >> >>> The last LTS was released 2018-10-02 [2]. >>>>> >> >>> >>>>> >> >>> Does that mean the next release (2.16) should be the next LTS? It >>>>> >> >>> looks like we are in danger of not living up to that promise. >>>>> >> >>> >>>>> >> >>> Cheers, >>>>> >> >>> Austin >>>>> >> >>> >>>>> >> >>> >>>>> >> >>> >>>>> >> >>> [1] https://beam.apache.org/community/policies/ >>>>> >> >>> >>>>> >> >>> [2] https://beam.apache.org/get-started/downloads/
