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