Core: Change removal of deprecations to 1.12.0 by gaborkaszab · Pull Request #14392 · apache/iceberg

gaborkaszab · 2025-10-21T15:57:33Z

No description provided.

nastra · 2025-10-22T09:37:32Z


 /**
- * @deprecated will be removed in 2.0.0. Use {@link
+ * @deprecated will be removed in 1.12.0. Use {@link


this one should be fine to remove before 2.0.0, since the property was only moved to a different class

nastra · 2025-10-22T09:39:47Z

 /**
 * @deprecated Use {@link SystemConfigs#WORKER_THREAD_POOL_SIZE WORKER_THREAD_POOL_SIZE} instead;
- * will be removed in 2.0.0
+ * will be removed in 1.12.0


this should be ok to remove earlier as well

github-actions · 2025-11-22T00:17:03Z

This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@iceberg.apache.org list. Thank you for your contributions.

pvary · 2025-11-22T07:37:54Z

Limit this to the ones which are trivial, and merge those

gaborkaszab · 2025-12-01T09:07:26Z

Thank you for taking a look @nastra and @pvary !
I remove the changes from TableProperties. Do you think the rest is reasonable?

pvary · 2025-12-05T09:28:51Z


 /**
- * @deprecated will be removed in 2.0.
+ * @deprecated will be removed in 1.12.0.


CC: @ggershinsky - is there any particular reason to keep these to 2.0?

should be ok to remove earlier.

gaborkaszab · 2025-12-09T13:30:46Z

 *
 * @param props table configuration
- * @deprecated use {@link MetricsConfig#forTable(Table)}
+ * @deprecated use {@link MetricsConfig#forTable(Table)}. Will be removed in 1.12.0


Change back to 2.0.0

gaborkaszab · 2025-12-09T13:38:38Z


 /**
- * @deprecated since 1.7.0, will be removed in 2.0.0; This method does only best-effort
+ * @deprecated since 1.7.0, will be removed in 1.12.0; This method does only best-effort


What is an alternative way to empty the cache?

@findepi Do you know any alternative way to invalidate all entries in the cache?
@pvary we discussed that we may want to leave the targeted removal for 2.0.0. However, this is a functionality we'd like the users to come off (due to the race condition) I think we should remove asap, so 1.12.0 still makes sense to me. WDYT?

Do you know any alternative way to invalidate all entries in the cache?
Depends on the goal.
if you invalidate just to reduce memory usage (rare), this method is fine
if you invalidate because something changed and all values needs to be recomputed (including those in flight), then there is no ready to use solution.
In trino we have additional layer on top of Guava caches that solves this problem. Here we use caffeine, but last time i checked, it had the same invalidation race problem and the author's feedback was that it was fundamentally not solvable.
thus, if full invalidation is needed, you can either copy code from trino-cache trino module (or use the code i already extracted https://github.com/findepi/evictable-cache)
Here i'd hope that invalidation isn't really needed for anything and we can remove the API.

gaborkaszab · 2025-12-09T13:49:13Z


 /**
- * @deprecated will be removed in 2.0.0, use {@link ViewBuilder#withLocation} instead.
+ * @deprecated will be removed in 1.12.0, use {@link ViewBuilder#withLocation} instead.


set back to 2.0.0

gaborkaszab · 2025-12-09T13:51:37Z

 }

- @Deprecated(since = "1.2")
+ /* @deprecated Will be removed in 1.12.0 */


check if tests pass without this

I think we can remove this once the PreparedStatement.setUnicodeStream is removed in JDK. It's out of our control, so I reset this change to original

I suggest to use @SuppressWarnings("deprecation") to get rid of the warning. Having @Deprecated(since = "1.2") is misleading. One might think that it is referring to the Iceberg 1.2 release

findepi · 2025-12-10T14:05:59Z


 /**
- * @deprecated will be removed in 2.0.0; use applyNameMapping and pruneColumns(Schema, Set)
+ * @deprecated will be removed in 1.12.0; use applyNameMapping and pruneColumns(Schema, Set)


did the deprecation removal rules change?
it looks like we considered not ok to remove a public API in a minor update, and now we conclude it's ok.
has this been discussed somewhere already?

There was a discussion about this in one of the community syncs. The conclusion was that we give guarantees for a whole major version in the api/ module, however in the core/ module we could be less strict and provide guarantees for one minor release. Technically deprecate in the upcoming minor, drop in the one after that is OK in core. Hence, this PR collects all the deprecations in core/ marking removal for 2.0.0 to revisit them and drop earlier if possible.

however in the core/ module we could be less strict and provide guarantees for one minor release
is this written down somewhere so that we can reference the rules of the games when deprecating?
community syncs meeting notes are not normative, we should capture important conclusions somewhere
btw, i don't think this 1 minor release guarantee means much in practice. maven world reality is that minor version update may just happen when combining various artifacts for the final delivery, so removing an API may obviously lead to MethodDefNotFoundError. This may be a fair trade off, i just hope it's a conscious one

Thanks for taking a look, @findepi !
Here are the docs for the api guarantees in different modules. It mentions one minor version guarantee in core module.

findepi · 2025-12-10T14:11:16Z


 /**
- * @deprecated since 1.7.0, will be removed in 2.0.0; This method does only best-effort
+ * @deprecated since 1.7.0, will be removed in 1.12.0; This method does only best-effort


Do you know any alternative way to invalidate all entries in the cache?
Depends on the goal.
if you invalidate just to reduce memory usage (rare), this method is fine
if you invalidate because something changed and all values needs to be recomputed (including those in flight), then there is no ready to use solution.
In trino we have additional layer on top of Guava caches that solves this problem. Here we use caffeine, but last time i checked, it had the same invalidation race problem and the author's feedback was that it was fundamentally not solvable.
thus, if full invalidation is needed, you can either copy code from trino-cache trino module (or use the code i already extracted https://github.com/findepi/evictable-cache)
Here i'd hope that invalidation isn't really needed for anything and we can remove the API.

pvary · 2025-12-12T11:42:43Z

Let's wait a bit more if somebody has any more comments

nastra · 2025-12-12T12:00:12Z

+ * @deprecated Use {@link AuthProperties#AUTH_TYPE}={@link AuthProperties#AUTH_TYPE_SIGV4}
+ * instead. Will be removed in 1.12.0.
+ */
+ @Deprecated private static final String SIGV4_ENABLED_LEGACY = "rest.sigv4-enabled";


this is actually a fallback mechanism so that older clients still work. When this property is removed, we want to make sure to switch the warn to an error msg but still leave the fallback mechanism in-place

Taking a second look, I just realize this is a private member, so technically this is already deprecated. I'll revert the changes here. because there isn't much we can do atm.

pvary · 2025-12-15T13:03:13Z

Merged to main.
Thanks @gaborkaszab for the PR and @nastra, @findepi, @ggershinsky for the review

…data to 1.13.0 The removal of the ability to write position deletes with row data (PDWR) was scheduled for 1.12.0 (see apache#17706). The 1.12.0 release candidate is being cut now and the removal touches public API across Core, Data and Spark 3.5/4.0/4.1, so it should not be rushed through review. This moves the removal target of those deprecations from 1.12.0 to 1.13.0. The deprecations themselves are unchanged: everything is still deprecated as of 1.11.0 and callers should still migrate off the row-carrying overloads. Only the stated removal release moves out by one cycle. This mirrors apache#14392, which retargeted a batch of removal versions in the other direction. Markers moved to 1.13.0: - PositionDelete.set(CharSequence, long, R) and row() - PositionDeleteWriter constructor (appender type narrowing) - RewriteTablePathUtil.PositionDeleteReaderWriter.writer(..., Schema) - GenericFileWriterFactory positionDeleteRowSchema constructors, the builder setter, and the nine configureDataWrite/configureEqualityDelete/ configurePositionDelete methods superseded by FormatModelRegistry, whose removal was bundled into the same change - SparkFileWriterFactory positionDeleteRowSchema/positionDeleteSparkType builder setters, the row-schema constructor, and the runtime warning message - SparkPositionDeltaWrite.Context.deleteSparkType() Additionally, PositionDeltaWriter.delete(CharSequence, long, T, PartitionSpec, StructLike) is now deprecated for removal in 1.13.0. It was previously not deprecated at all, so without this its deprecation cycle would only start in 1.13.0 and the row parameter could not be dropped until 1.14.0. Deprecating it here keeps that narrowing on schedule for 1.13.0 alongside the rest. The annotation is additive: the overload stays abstract, so implementations are unaffected, while callers can migrate to the four-argument overload today. All three SparkPositionDeltaWrite call sites already use it; the only override is BasePositionDeltaWriter, which already calls the deprecated PositionDelete.set(CharSequence, long, R). Flink is not deferred. Its only PDWR surface was FlinkAppenderFactory, whose entire position delete path is built on row data. That class was deprecated as of 1.11.0 in favor of FlinkFileWriterFactory for removal in 1.12.0, and nothing in the repo references it outside its own test, so it is removed here on schedule from all three Flink versions rather than carried into 1.13.0. That also drops org.apache.iceberg.io.TestAppenderFactory from iceberg-data: the three TestFlinkAppenderFactory classes were its only subclasses, so with those gone the abstract base exercises nothing. iceberg-flink is not a revapi project and TestAppenderFactory is a test class, so neither removal needs a revapi baseline entry. The REST scan-planning markers in BaseScanTaskResponse, PlanTableScanRequest and PlanTableScanResponse are left alone; they are handled separately in apache#17638.

@deprecated

…log message (#17812) * Core: Remove ThreadPools.WORKER_THREAD_POOL_SIZE_PROP and correct manifest spec fallback removal version Resolves the two remaining deprecation markers in iceberg-core that promised action "in 1.12.0" but were missed by the removal PRs. Remove ThreadPools.WORKER_THREAD_POOL_SIZE_PROP. The field was deprecated in #5659 in favor of SystemConfigs.WORKER_THREAD_POOL_SIZE and retargeted from 2.0.0 to 1.12.0 by #14392. It had no callers anywhere in the repository outside its own declaration and no references in the docs, and it was the only survivor of #14392's 13-file batch after #17700 removed the rest. The corresponding java.field.removed break is recorded in .palantir/revapi.yml under the 1.11.0 baseline. Correct the ManifestReader warning for the partition-spec-from-file- metadata fallback to say 2.0.0 rather than 1.12.0. The fallback cannot be honored in 1.12.0 because its only production caller is BaseSnapshot:276, which passes a null spec map while serving Snapshot.addedDeleteFiles(FileIO) and removedDeleteFiles(FileIO). Those accessors are themselves already marked "@deprecated will be removed in 2.0.0; use SnapshotChanges#builderFor(Table) instead", and because they receive only a FileIO they structurally cannot supply a spec map. The fallback must therefore outlive 1.12.0, and 2.0.0 aligns its removal with that of its last caller. * reword revapi change

github-actionsBot added the core label Oct 21, 2025

nastra reviewed Oct 22, 2025
View reviewed changes

Comment threadcore/src/main/java/org/apache/iceberg/TableProperties.java Outdated

nastra reviewed Oct 22, 2025
View reviewed changes

Comment threadcore/src/main/java/org/apache/iceberg/util/ThreadPools.java Outdated

nastra reviewed Oct 22, 2025
View reviewed changes

github-actionsBot added the stale label Nov 22, 2025

github-actionsBot removed the stale label Nov 23, 2025

gaborkaszab force-pushed the main_change_deprecations_core branch from c05ed54 to 398b988Compare December 1, 2025 08:51

gaborkaszab force-pushed the main_change_deprecations_core branch from 398b988 to 82673e6Compare December 1, 2025 09:12

pvary reviewed Dec 5, 2025
View reviewed changes

gaborkaszab commented Dec 9, 2025
View reviewed changes

findepi reviewed Dec 10, 2025
View reviewed changes

gaborkaszab force-pushed the main_change_deprecations_core branch from 82673e6 to 5bcdeabCompare December 10, 2025 14:15

pvary approved these changes Dec 12, 2025
View reviewed changes

nastra reviewed Dec 12, 2025
View reviewed changes

nastra approved these changes Dec 12, 2025
View reviewed changes

Core: Change removal of deprecations to 1.12.0
fc02d3a

gaborkaszab force-pushed the main_change_deprecations_core branch from 5bcdeab to fc02d3aCompare December 12, 2025 14:47

pvary merged commit 831b4ea into apache:mainDec 15, 2025
44 checks passed

talatuyarer pushed a commit to talatuyarer/iceberg that referenced this pull request Apr 1, 2026
Core: Change removal of deprecations to 1.12.0 (apache#14392)
d929b55

Uh oh!

Conversation

gaborkaszab commented Oct 21, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actionsBot commented Nov 22, 2025

Uh oh!

pvary commented Nov 22, 2025

Uh oh!

gaborkaszab commented Dec 1, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pvary commented Dec 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

pvary commented Dec 15, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants