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