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