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