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