+1 to starting with 2.7 branch and supporting it for 6 months. I think we should start the support window of 6 months from the day we agree to do this. That way users will at least get the benefit for 6 months after learning about LTS status.
It seems like there is a consensus. Should we hold a vote on this? On Mon, Nov 5, 2018 at 6:46 AM, Robert Bradshaw <rober...@google.com> wrote: > Yes, cutting more patch releases is the goal of the LTS release. We > have not yet determined what the threshold is for backporting bugfixes > (which, in part, depends on how much work that is) nor how often we'd > do a release. > How about we start tagging issues with a fix version 2.7.1 and a do a case by case decision. Over time we could write down common patterns that we used for deciding what to backport. > > On Mon, Nov 5, 2018 at 3:42 PM Chamikara Jayalath <chamik...@google.com> > wrote: > > > > +1 for using an existing release. > > > > Regarding set of issues, I think so far the policy has been that we cut > patch releases for major issues such as security fixes or major breakages > of functionality (we only did one patch release so far IIRC). Are we going > to change this policy ? For example, are we going to cut regular patch > releases for supported branch (release-2.7.0) within the supported period > that fixes known issues ? My preference is to keep existing policy on this > regard. > > > > Thanks, > > Cham > > > > On Mon, Nov 5, 2018 at 5:12 AM Robert Bradshaw <rober...@google.com> > wrote: > >> > >> Indeed, that's a vary good signal. > >> > >> I propose we start with the 2.7 branch (which has been out in the wild > >> for a bit and seems pretty stable), supported for 6 months (from > >> now?). We should gather a list of issues, if any, that merit > >> backporting. > >> On Mon, Nov 5, 2018 at 11:07 AM Maximilian Michels <m...@apache.org> > wrote: > >> > > >> > The result shows that there is a demand for an LTS release. > >> > > >> > +1 for using an existing release. How about six months for the initial > >> > LTS release? I think it shouldn't be too long for the first one to > give > >> > us a chance to make changes to the model. > >> > > >> > -Max > >> > > >> > On 02.11.18 17:26, Ahmet Altay wrote: > >> > > Twitter vote concluded with 52 votes with the following results: > >> > > - 52% Stable LTS releases > >> > > - 46% Upgrade to latest release > >> > > - 2% Keep using older releases > >> > > > >> > > This reads like another supporting evidence for making LTS > releases. In > >> > > the light of this, what do you all think about Kenn's proposal of > making > >> > > existing branch an LTS branch? > >> > > > >> > > On Thu, Oct 25, 2018 at 4:18 PM, Ahmet Altay <al...@google.com > >> > > <mailto:al...@google.com>> wrote: > >> > > > >> > > > >> > > > >> > > On Tue, Oct 23, 2018 at 3:03 PM, Kenneth Knowles < > k...@apache.org > >> > > <mailto:k...@apache.org>> wrote: > >> > > > >> > > Yes, user@ cannot reach new users, really. Twitter might, > if we > >> > > have enough of adjacent followers to get it in front of the > >> > > right people. On the other hand, I find testimonials from > >> > > experience convincing in this case. > >> > > > >> > > > >> > > I agree I am not sure how much additional input we will get > from a > >> > > twitter poll. Started one anyway > >> > > (https://twitter.com/ApacheBeam/status/1055598972423684096 > >> > > <https://twitter.com/ApacheBeam/status/1055598972423684096>). > I used > >> > > Thomas's version as the basis and had to shorten it to fit the > >> > > character limits. > >> > > > >> > > > >> > > Kenn > >> > > > >> > > On Tue, Oct 23, 2018 at 2:59 PM Ahmet Altay < > al...@google.com > >> > > <mailto:al...@google.com>> wrote: > >> > > > >> > > > >> > > > >> > > On Tue, Oct 23, 2018 at 9:16 AM, Thomas Weise > >> > > <t...@apache.org <mailto:t...@apache.org>> wrote: > >> > > > >> > > > >> > > > >> > > On Mon, Oct 22, 2018 at 2:42 PM Ahmet Altay > >> > > <al...@google.com <mailto:al...@google.com>> wrote: > >> > > > >> > > We attempted to collect feedback on the mailing > >> > > lists but did not get much input. From my > experience > >> > > (mostly based on dataflow) there is a sizeable > group > >> > > of users who are less interested in new > features and > >> > > want a version that is stable, that does not > have > >> > > security issues, major data integrity issues > etc. In > >> > > Beam's existing release model that corresponds > to > >> > > the latest release. > >> > > > >> > > It would help a lot if we can hear the > perspectives > >> > > of other users who are not present here through > the > >> > > developers who work with them. > >> > > > >> > > > >> > > Perhaps user@ and Twitter are good ways to reach > >> > > relevant audience. > >> > > > >> > > > >> > > We tried user@ before did not get any feedback [1]. > Polling > >> > > on twitter sounds like a good idea. Unless there is an > >> > > objection, I can start a poll with Thomas's proposed > text as > >> > > is on Beam's twitter account. > >> > > > >> > > [1] > >> > > https://lists.apache.org/thread.html/ > 7d890d6ed221c722a95d9c773583450767b79ee0c0c78f48a56c7eba@% > 3Cuser.beam.apache.org%3E > >> > > <https://lists.apache.org/thread.html/ > 7d890d6ed221c722a95d9c773583450767b79ee0c0c78f48a56c7eba@% > 3Cuser.beam.apache.org%3E> > >> > > > >> > > > >> > > A poll could look like this: > >> > > > >> > > The Beam community is considering LTS (Long Term > >> > > Support) for selected releases. LTS releases would > only > >> > > contain critical bug fixes (security, data integrity > >> > > etc.) and offer an alternative to upgrading to > latest > >> > > Beam release with new features. Please indicate your > >> > > preference for Beam upgrades: > >> > > > >> > > 1) Always upgrading to the latest release because I > need > >> > > latest features along with bug fixes > >> > > 2) Interested to switch to LTS releases to obtain > >> > > critical fixes > >> > > 3) Not upgrading (using older release for other > reasons) > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >
