On 2026/06/04 20:17:45 Ryan Blue wrote: What’s a preset? Could you describe the idea in this discussion so we can keep it in one place?
The concept was introduced earlier in this thread by Antoine. Thank you. I’m not sure how I missed it in my first pass through the thread. I would like once again to propose that, instead of editorializing version numbers (for example a mythical “V3” with a curated subset of recent features), we define “profiles” or “presets” purely based on calendar adoption of features. Before responding to the preset idea, I want to note that the version numbers we are talking about aren’t editorializing. The idea isn’t a big marketing splash around Parquet 3. Instead, think of it as a compatibility identifier or epoch. Breaking changes go into the next open version (right now, v3) and when it is finalized, people can reason about compatibility using those numbers. For example, if Trino were to document support for version 3, it would mean that it supports all of the breaking changes in version 3. The purpose of this is to more easily and clearly communicate compatibility across projects. Downstream users want to know what projects work together. They do that at a high level, not at the granularity of individual changes. I would never expect a user to ask “does this version of Trino support files that didn’t write path_in_schema?” [A preset] gives us a mechanistic process for definining compatibility levels based on actual feature adoption in the main implementations (which is also, implicitly, a measure of how useful those features are). I don’t think that the preset idea is a good solution to the problem. We may even be trying to address different problems. As I understand it from the description in this thread, a preset gives a snapshot of the things that are common to a subset of implementations, say Java, Rust, and C++. It would also give users a way to ask some questions, like “when was ALP supported?” in all 3. But that isn’t sufficient for checking compatibility when there are other implementations. A big issue is that vendors have custom implementations that aren’t covered. Other implementations could document their compatibility with presets, but only after the time-based milestone because we don’t know what’s in a preset until the time passes. A preset also doesn’t give useful control over compatibility. Let’s assume I’m only using implementations that are part of the preset list. If I have an engine that uses an older C++ version, how does a preset help me maintain compatibility with it? If I understand correctly, the oldest preset (that C++ library) would determine which write-side features I am able to switch on. Do I need to go update a config file of flags somewhere to do that? I think there are reasonable fixes for both of these issues with presets. That is to think about a preset as a set of features bundled together for compatibility. Other implementations document the preset they are compatible with, and users switch on features by using the newest preset supported by all of their readers. But at this point, a preset as a bundle of features is basically the same thing as a version number. It’s a bundle of features you switch on as a group. If we view presets as bundles of features, then I’m more supportive. But there are still odd drawbacks: presets are defined after-the-fact by what was supported on a certain date. That makes them harder to predict and requires that we go figure out what was supported and write it down. The version alternative allows us to document the version that has a particular feature when we add it, rather than going back to find out what made it into the bundle. Another drawback of presets is that it doesn’t require agreement. A feature that is not supported by any of the 3 implementations never makes it into a preset. Versioning makes this simpler because we all get to determine what gets added as we make changes, and finalizing a version lets us review that list. The list is also constantly available so that all implementations can keep up with it before it is finalized. I guess to me, the useful parts of the preset idea are already included in versions, and they are built in a way that I don’t find particularly helpful. Ryan On Thu, Jun 4, 2026 at 1:39 PM Ed Seidl <[email protected]> wrote: > On 2026/06/04 20:17:45 Ryan Blue wrote: > > What's a preset? Could you describe the idea in this discussion so we can > > keep it in one place? > > > > The concept was introduced earlier in this thread by Antoine. > https://lists.apache.org/thread/gvw48wrkhgl83jljhd1hzb668ys9zvqx > > Cheers, > Ed >
