Improvements to feature flagging and handling of breaking changes

Is your feature request related to a problem?

New features and bugfixes can lead to breaking changes. These are generally for the better, but can sometimes have a wide impact that can affect users in different ways.

This is highlighted where possible - PR titles, release notes, newsletter. Any migration info should be added to the docs at the relevant section. We also may provide config options to control the new behaviour, where appropriate.

Let's look at examples. Here's a narrower change:

https://github.com/questdb/questdb/pull/4277

In this case, no feature was gained or removed, but a default was changed. This only affected one style of query, and providing a config option is relatively low impact long term. The aim of the PR was to improve baseline performance for most users, so in general a strong upside.

https://github.com/questdb/questdb/pull/4443

In this PR, the impact is wider reaching, since it fundamentally changes the manner in which SQL queries are parsed. Each user could have breakages for any of their queries. In the long run, a config option to disable the changes is not ideal to maintain. Therefore, a temporary config option was added, which will allow users to delay the changes if they need to take the newest bug fixes. Such an option should be targeted for removal in the following version (i.e if in 7.4.3, gone in 7.4.4).

Overall, a clearer means to manage feature flags that's transparent to both users and maintainers could be useful, without over-complicating the situation or being too inflexible to user needs.

Describe the solution you'd like.

Some possible ideas

• A more 'formal' way to handle temporary config options/feature flags
• Deprecation of config options (logging warnings when an option is no longer in-use)
• Some sort of compatibility mode, or checks to warn about the possible impact
• Addition of breaking change notes to startup logs for the relevant version.

This is an issue for ideas and not a clear plan! We welcome comments and discussion on how best to approach this.

Describe alternatives you've considered.

No response

Full Name:

Nick Woolmer

Affiliation:

QuestDB

Additional context

No response

Start by reviewing the issue and the referenced PRs 4277 and 4443 to understand the existing configuration and breaking-change patterns. Compare the proposed approaches—temporary flags, deprecation warnings, compatibility checks, and startup notes—and define a focused design with clear removal or completion criteria; the issue does not name files or tests.