Hi Maksim and all,
Sorry for the necropost and for the long read!
First of all, Maksim, thank you for tackling this. It's been a long time
coming for sure.
I know I'm late to the party but I'd like to ask to give this change
another look - and, for some features, do a follow up and a vote.
TLDR:
- Impact of promoting features from Experimental is serious, and from
something like Calcite it's *HUGE*.
- The mere fact that something has been there for a long time is a hint
that a promotion is possible, but not sufficient on its own.
- There needs to be a way to signal prod-readiness, not just API stability;
many do understand Experimental to mean that (perhaps, incorrectly).
- Proposal:
- Review the list of promoted features in groups/batches.
- Vote on big feature promotions.
- Create a formal IEP on feature lifecycle (Experimental, GA, Deprecated)
that covers both API stability and prod-readiness.
- Create a wiki doc with feature registry, including their status.
I looked up when @IgniteExperimental was introduced (see `[DISCUSS] Public
API deprecation rules` thread from Feb 2020). To my surprise, back then the
conversation was indeed mostly about API stability, not overall feature
stability. I always treated `@IgniteExperimental` more as beta vs GA, and I
know other people did as well - if we say that it only means API stability,
then the name is confusing; in most projects, and most notably in Java,
Experimental means "not ready for prod" which includes, but not limited to,
the API. At the very least, the expectation is that promoted features are
now fully supported and dependable going forward, and I'm not sure if
that's the correct signal for all of them.
Out of the features promoted in this patch (+ also CDC promoted recently),
a few stand up in particular. Calcite promotion has huge implications
(stability, performance, maintenance, DevEx), some features probably need a
replacement for the experimental flag (binary meta management is explicitly
unsafe to use and needs a big red flag for that).
I'd say there are a few groups that could need different treatment:
- Maintenance mode classes - these are implementation classes, it isn't an
API feature; the annotations can indeed be removed.
- System properties - instead of promoting, why not remove them? If they
are needed, let's move them to IgniteConfiguration; if not, just remove
them. There is also an option to make them "private", i.e. keep the
property fetching in the component's internal classes as a backdoor tuning
option, but not as a public API.
- Niche and/or low-risk - probably easy to agree on without a vote but
deserve more explicit discussion:
- JDBC Partition Awareness - if it works and has no stability concerns,
no reason not to promote;
- Service interceptors;
- .NET platform cache;
- `RegexpMetricFilter`;
- Graceful shutdown / ShutdownPolicy
- Graceful shutdown needs docs updated as they now point to the
deprecated property without the Experimental tag.
- System views;
- `forceClientToServerConnections`.
- Small but somewhat impactful - need to make sure people actually want to
support those going forward; deserve a bulk vote on the group:
- Binary meta management
- IMO very much needed but also risky.
- Tracing - Any performance concerns? The feature is pretty huge - I
wonder if people will be ready to maintain it?
- Performance statistics - Any performance concerns?
- CDC - Any limitations, any performance concerns? Is it really an
extension given that support for it lives in the core?
- IndexQuery - small but everyone uses it.
- Shouldn't it be merged with ScanQuery? "Index" hints that it'll be
using a secondary index but that's rather irrelevant for the user; people
like it because it gives them a way to write `WHERE X > ?` in pure Java.
- Very impactful - deserves a vote:
- Calcite - this isn't just a feature, IMO this has strategic impact for
the project.
- Even skipping the argument of whether it's stable, I'd say that
having two fully-supported SQL engines in one platform is one too many. If
Calcite is ready, let's deprecate H2. But keeping
`QueryEngineConfiguration` in the public API suggests that engines will be
chooseable forever; I don't think there is a single SQL database out there
that allows you to choose between two completely parallel SQL engines.
I propose we address these groups differently in different threads and
implement the follow-up changes as needed, as well as write an IEP on the
lifecycle to make this more structured in future. I can volunteer for this
if no one objects to the approach.
WDYT?
Thanks,
Stan
On Mon, Feb 16, 2026 at 8:09 AM Maksim Timonin <[email protected]>
wrote:
> Hi,
>
> >> Please make sure others status. Every feature's status should be
> rechecked separately, not in a "aged" way
>
> Yes, that is correct. I proposed the "aged" way to limit the scope of
> the investigation (all experimental APIs from 2.17 remain experimental,
> including CdcManager).
>
> I've verified each removed flag with component maintainers. Thanks to
> everyone who helped review them. All approved [1] API now are no longer
> experimental.
>
> [1] https://github.com/apache/ignite/pull/12739
>
>
>
> On Fri, Feb 13, 2026 at 6:39 PM Dmitriy Pavlov <[email protected]> wrote:
>
> > +1 I support this proposal, as the following top-level features have
> been
> > stable and used for multiple releases: IndexQuery, Read Repair, Dumps,
> and
> > the TCP communication configuration initializer.
> >
> > Regarding Calcite in 2.x, I’m not sure it should become the default in
> the
> > upcoming release, but it should no longer be considered beta;
> >
> > And finally, the experimental flag is not about motivating someone to
> > finish all possible improvements — it is about API stability and whether
> > breaking changes are expected.
> >
> > пт, 13 февр. 2026 г. в 11:53, Anton Vinogradov <[email protected]>:
> >
> > > Strong -1
> > > If something was not finished even years ago, it does not mean it
> becomes
> > > automatically finished now.
> > > Removing this flag gives no chance to finish the work in future.
> > >
> > > Чт, 12 февр. 2026 г. в 10:38, Maksim Timonin <[email protected]
> >:
> > >
> > > > Hi Stephen,
> > > >
> > > > There are actually two points to discuss.
> > > >
> > > > First, regarding the @IgniteExperimental annotation: according to its
> > > > Javadoc, is not a "beta" tag but rather an indication that the API is
> > not
> > > > yet finalized. Currently, we lack specific annotations to distinguish
> > > > between alpha/beta/stable status. Therefore, removing the
> > > > @IgniteExperimental simply signals that the API is now stable and
> users
> > > > needn't worry about it being completely redesigned in the next
> release.
> > > >
> > > > Secondly, regarding Calcite: I believe the Calcite engine is stable.
> > Our
> > > > internal benchmarks show that Calcite performs well. Furthemore, all
> > new
> > > > SQL features (such as memory quotas, SQL transactions [1],
> > SessionContext
> > > > [2]) are being developed exclusively for Calcite. Users should be
> > > > encouraged to migrate to Calcite, especially given the outdated H2
> > > version
> > > > and the fact there has been no active development in the H2 component
> > for
> > > > several releases.
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-125+Transactions+aware+queries
> > > > [2]
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-129%3A+Application+attributes+and+SessionContext+API
> > > >
> > > > On Wed, Feb 11, 2026 at 5:48 PM Stephen Darlington <
> > > [email protected]
> > > > >
> > > > wrote:
> > > >
> > > > > Agree in principle, but I suspect some will warrant a wider
> > discussion.
> > > > For
> > > > > example, if the Calcite configuration option is no longer
> > experimental,
> > > > > that would suggest that the Calcite engine is no longer in beta. Is
> > > that
> > > > > correct?
> > > > >
> > > > > On Wed, 11 Feb 2026 at 14:44, Pavel Tupitsyn <[email protected]
> >
> > > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > On Wed, Feb 11, 2026 at 3:14 PM Maksim Timonin <
> > > > [email protected]>
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi Igniters,
> > > > > > >
> > > > > > > Before starting the 2.18 release process, I'd like to propose
> > > > removing
> > > > > > the
> > > > > > > @IgniteExperimental annotation from several APIs that have been
> > > > > available
> > > > > > > for a long time and are actually stable (they haven't changed
> > since
> > > > > their
> > > > > > > initial release). Some of such APIs are already used by our
> > users.
> > > > > > >
> > > > > > > The "experimental" tag often discourages users from adopting
> > these
> > > > > APIs,
> > > > > > as
> > > > > > > it creates an impression that the functionality is "half-baked"
> > or
> > > > > > subject
> > > > > > > to breaking changes. Especially, when such flags persist over
> > > > multiple
> > > > > > > releases, for years.
> > > > > > >
> > > > > > > Specifically, I propose removing @IgniteExperimenal from all
> APIs
> > > > > > > introduced in version 2.16 or earlier. Any future changes to
> > these
> > > > APIs
> > > > > > > should follow the standard process: deprecation first, if
> > required.
> > > > > > >
> > > > > > > I recall our agreement that we can deprecate and remove APIs in
> > > > > > > even-numbered releases. So, I believe this proposal aligns
> > > perfectly
> > > > > with
> > > > > > > our policy.
> > > > > > >
> > > > > > > WDYT?
> > > > > > >
> > > > > > > 1. org.apache.ignite.spi.tracing.* - released in 2.10.
> > > > > > > 2. org.apache.ignite.IgniteServices#serviceProxy - released in
> > > 2.13.
> > > > > > > 3. org.apache.ignite.cache.query.IndexQuery - released in 2.12.
> > > > > > > 4. org.apache.ignite.calcite.CalciteQueryEngineConfiguration -
> > > > released
> > > > > > in
> > > > > > > 2.13.
> > > > > > > 5. org.apache.ignite.IgniteCache#withReadRepair and
> > > > > > > org.apache.ignite.cache.ReadRepairStrategy - released in 2.13.
> > > > > > > 6.
> > > > IgniteSystemProperties#IGNITE_ENABLE_SUBQUERY_REWRITE_OPTIMIZATION -
> > > > > > > released in 2.10.
> > > > > > > 7. IgniteSystemProperties#IGNITE_SNAPSHOT_SEQUENTIAL_WRITE -
> > > released
> > > > > in
> > > > > > > 2.15.
> > > > > > > 8. IgniteSystemProperties#IGNITE_CONFIGURATION_VIEW_PACKAGES -
> > > > released
> > > > > > in
> > > > > > > 2.15.
> > > > > > > 9. org.apache.ignite.cache.CacheEntryVersion - released in
> 2.12.
> > > > > > > 10.
> > > > org.apache.ignite.CacheConfiguration#getPlatformCacheConfiguration
> > > > > -
> > > > > > > released in 2.9.
> > > > > > > 12. org.apache.ignite.dump.* - released in 2.16.
> > > > > > > 13.
> > > > > >
> > > > >
> > > >
> > >
> >
> org.apache.ignite.spi.communication.tcp.*internal*.TcpCommunicationConfigInitializer
> > > > > > > - released in 2.9.
> > > > > > >
> > > > > > > Also, for fun - both @IgniteExperimental and @Deprecated:
> > > > > > > 1. IgniteSystemProperties#IGNITE_WAIT_FOR_BACKUPS_ON_SHUTDOWN
> > > > > > > 2. org.apache.ignite.mxbean.PerformanceStatisticsMBean
> > > > > >
> > > > >
> > > >
> > >
> >
>
