Hi I think we are all on the same page. My point is that it's a lot of effort to maintain a LTS. So, I don't think we are at this point yet.
I think we should focus on the "active" branch for now. We can always do "patch" release on previous release branches if needed. Regards JB On Tue, Mar 3, 2026 at 2:01 PM Adnan Hemani via dev <[email protected]> wrote: > My personal thought is that we may be too young for necessitating "LTS" > and/or multiple (more than 2) "active" branches. > > I agree with Dmitri: perhaps we should only keep 2 active releases (latest > minor, not patch, releases; currently 1.3.0 and 1.2.0) that the community > maintains for backporting. Users on older releases can always maintain > their own backporting forks, if they need. > > Best, > Adnan Hemani > > On Tue, Mar 3, 2026 at 10:53 AM Dmitri Bourlatchkov <[email protected]> > wrote: > > > Hi All, > > > > By an "active release" do we mean a release for which we agree to > > back-porting critical bug fixes? > > > > In that case, 3 active releases (as Yufei proposed) may still be too > many, > > IMHO. As of today, this means 1.3.0, 1.2.0 and 1.1.0... however, the > > code in 1.1.0 is extremely old compared to the current "main". Is it > worth > > trying to "fix"? > > > > .... although, I do not oppose that if other people agree. > > > > From my point of view, 2 active releases are more manageable. When 1.4.0 > > finalizes, 1.3.0 will remain active, and receive critical fixes, allowing > > users some time to migrate to the latest release. > > > > Users who linger on very old releases are still free to contribute > backport > > PRs, and request patch releases, but the community as a whole will not > have > > an obligation to perform those backports "automatically". > > > > WDYT? > > > > Thanks, > > Dmitri. > > > > On Tue, Mar 3, 2026 at 1:38 PM Yufei Gu <[email protected]> wrote: > > > > > Keeping 3 active releases makes sense to me. I would prefer not to > > > introduce an LTS branch until there is a clear and concrete need. As a > > > reference, we could look at the Spark versioning policy[1]. We could do > > > something similar when we aims for Polaris 2.0. > > > > > > The last minor release within a major release will typically be > > maintained > > > > for longer as an “LTS” release. For example, 3.5.0 was released on > > > > September 13th 2023 and will be maintained for 31 months until April > > 12th > > > > 2026. > > > > > > > > > [1] https://spark.apache.org/versioning-policy.html > > > > > > Yufei > > > > > > > > > On Tue, Mar 3, 2026 at 9:52 AM Michael Collado <[email protected] > > > > > wrote: > > > > > > > Maintaining an ongoing "LTS" branch sounds like a lot of work that, > > IMO, > > > > will be hard to sustain. While I think emergency patches to previous > > > minor > > > > releases, IMO those are rare and don't require the ongoing effort of > > > > maintaining a separate LTS branch. > > > > > > > > Mike > > > > > > > > On Tue, Mar 3, 2026 at 6:41 AM Dmitri Bourlatchkov <[email protected] > > > > > > wrote: > > > > > > > > > Hi JB, > > > > > > > > > > I'm not sure about an active LTS branch at this point. > > > > > > > > > > A lot of feature and refactoring work is going on in "main" (e.g. > > > > > authorization SPI, Admin CLI, Per-table credentials...). > Back-porting > > > > fixes > > > > > that rely on previously refactored code can be a non-trivial task > > > > > especially if we do it on a regular basis (which the term "active" > > > > > implies). > > > > > > > > > > Cheers, > > > > > Dmitri. > > > > > > > > > > On Tue, Mar 3, 2026 at 8:52 AM Jean-Baptiste Onofré < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > Right now we have a single active branch, which I think is fine > for > > > the > > > > > > time being. We can add another active branch when needed. > > > > > > > > > > > > Based on my experience, I suggest maintaining two active > branches: > > > LTS > > > > > and > > > > > > dev. The maintenance effort, such as cherry-picking, is generally > > > > > > manageable at this level. However, having more than two branches > > > > > > significantly increases the maintenance burden, so I would prefer > > to > > > > > avoid > > > > > > going beyond that. > > > > > > > > > > > > Regards, > > > > > > JB > > > > > > > > > > > > Le mar. 3 mars 2026 à 08:42, Alexandre Dutra <[email protected]> > a > > > > > écrit : > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > While working on the web site lately I noticed that it had some > > > > > > > tooling to distinguish between "active" and "end-of-life" (EOL) > > > > > > > releases. The tooling wasn't effective until recently, and > while > > > > > > > working on the Documentation [1] and Downloads/Releases [2] > > > sections, > > > > > > > I started to make the distinction visible. > > > > > > > > > > > > > > The visual intent is simple: highlight "active" releases (both > > > > > > > documentation and downloads) while limiting the display of old > > > items > > > > > > > to prevent cluttering dropdown menus and sidebars with outdated > > > > > > > information that tend to accumulate over time. > > > > > > > > > > > > > > But we'd need to establish an official policy for defining > which > > > > > > > releases are supported and which have reached EOL. > > > > > > > > > > > > > > Currently, my simple, informal approach considers the latest > > bugfix > > > > > > > versions across the three most recent minor releases as > "active." > > > > This > > > > > > > currently includes versions 1.3.0, 1.2.0, and 1.1.0. > > > > > > > > > > > > > > Other approaches are obviously possible. It also depends a lot > on > > > the > > > > > > > release cadence. I'd appreciate your input and thoughts on > > > > > > > establishing a formal policy for this. > > > > > > > > > > > > > > Thanks, > > > > > > > Alex > > > > > > > > > > > > > > [1]: https://github.com/apache/polaris/pull/3876 > > > > > > > [2]: https://github.com/apache/polaris/pull/3902 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
