Hi all, Overall, it is a good idea to provide the LTS release, but I'd like to reference a concrete case as an example to understand what restrictions the LTS should have.
Hypothetically, Source-/Sink- Function have been deprecated in 1.x LTS and removed in 2.0 and the issues[1] are not solved in 2.0. This is a typical scenario that the old APIs are widely used in 1.x LTS and the new APIs in 2.0 are not ready yet to take over all users. We will have the following questions: 1. Is this scenario allowed at all? Do we all agree that there could be some features/functionalities that only work in 1.x LTS after 2.0 has been released? 2. How long are we going to support 1.x LTS? 1 year? 2 years? As long as the issues that block users from migrating to 2.0 are not solved, we can't stop the LTS support, even if the predefined support time expires. 3. What is the intention to release a new version with (or without) LTS? Do we still want to engage users to migrate to the new release asap? If the old APIs 1.x LTS offer more than the new APIs in 2.0 or it is almost impossible to migrate, double effort will be required to maintain those major releases for a very long time. We will be facing many cohorts. IMHO, we should be clear with those questions before we start talking about LTS. WDYT? Best regards, Jing [1] https://lists.apache.org/thread/734zhkvs59w2o4d1rsnozr1bfqlr6rgm On Tue, Jul 25, 2023 at 6:08 PM Márton Balassi <balassi.mar...@gmail.com> wrote: > 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 > > >
