Hi team, +1 for supporting the last 1.x for a longer than usual period of time and limiting it to bugfixes. I would suggest supporting it for double the usual amount of time (4 minor releases).
On Tue, Jul 25, 2023 at 9:25 AM Konstantin Knauf <kna...@apache.org> wrote: > Hi Alex, > > yes, I think, it makes sense to support the last 1.x release longer than > usual. This should be limited to bugfixes in my opinion. > > Best, > > Konstantin > > Am Di., 25. Juli 2023 um 07:07 Uhr schrieb Xintong Song < > tonysong...@gmail.com>: > > > Hi Alex, > > > > Providing a longer supporting period for the last 1.x minor release makes > > sense to me. > > > > I think we need to be more specific about what LTS means here. > > > > - IIUC, that means for the last 1.x minor release, we will keep > > providing 1.x.y / 1.x.z bugfix release. This is a stronger support > > compared > > to regular minor releases which by default are only supported for 2 > > minor > > release cycles. > > - Do we only provide bug fixes for the LTS release, or do we also > allow > > backporting features to that release? > > - How long exactly shall we support the LTS release? > > > > And maybe we can make this a general convention for last minor releases > for > > all major releases, rather than only discuss it for the 2.0 version bump. > > > > @Leonard, > > > > I'd like to clarify that there are no community decisions yet on release > > 2.0 after 1.19. It is possible to have 1.20 before 2.0. > > > > Best, > > > > Xintong > > > > > > > > On Tue, Jul 25, 2023 at 11:54 AM Leonard Xu <xbjt...@gmail.com> wrote: > > > > > +1, it’s pretty necessary especially we deprecated so many APIs in 1.18 > > > and plan to remove in 2.0. > > > > > > The 1.19 should be a proper version for LTS Release. > > > > > > Best, > > > Leonard > > > > > > > > > > On Jul 25, 2023, at 3:30 AM, Alexander Fedulov < > > > alexander.fedu...@gmail.com> wrote: > > > > > > > > Hello everyone, > > > > > > > > Recently, there were a lot of discussions about the deprecation of > > > various > > > > APIs for the upcoming 2.0 release. It appears there are two main > > > motivations > > > > with opposing directions, causing these discussions to remain > > unsettled. > > > On > > > > one hand, there's a desire to finally trim a wide range of legacy > APIs, > > > some > > > > lingering around since the beginning of the 1.x release line (as far > > > back as > > > > 2016). On the other hand, there is a commitment to uphold our > > guarantees > > > to > > > > the users, ensuring a smooth transition. > > > > > > > > I believe we could reconcile these two motivations. My proposition is > > to > > > > designate the final release of the 1.x timeline as a Long-Term > Support > > > (LTS) > > > > release. By doing so, we would: > > > > > > > > 1. Enable more efficient cleanup and be liberated to introduce more > > > breaking > > > > changes, paving the way for greater innovation in the 2.0 release. > > > > 2. Sustain a positive user experience by granting enough time for the > > > > changes > > > > introduced in 2.0 to stabilize, allowing users to confidently > > > transition > > > > their production code to the new release. > > > > > > > > I look forward to hearing your thoughts on this proposal. > > > > > > > > Best Regards, > > > > Alex > > > > > > > > > > > -- > https://twitter.com/snntrable > https://github.com/knaufk >
