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