Mark IPlatformConfiguration/Factory for removal

[laeubi]

These interfaces are currently only used by ConfiguratorUtils that is already marked for removal on 2024-03

See

• ConfigurationActivator should lazy load the PlatformConfiguration #1572

[eclipse-platform-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

update/org.eclipse.update.configurator/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From b0f4fa4a2f4e3998ce976024320fc5f3b14d1b03 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <[email protected]>
Date: Sat, 3 May 2025 04:53:03 +0000
Subject: [PATCH] Version bump(s) for 4.36 stream


diff --git a/update/org.eclipse.update.configurator/META-INF/MANIFEST.MF b/update/org.eclipse.update.configurator/META-INF/MANIFEST.MF
index 5f045c7318..f1a5deb034 100644
--- a/update/org.eclipse.update.configurator/META-INF/MANIFEST.MF
+++ b/update/org.eclipse.update.configurator/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %pluginName
 Bundle-SymbolicName: org.eclipse.update.configurator; singleton:=true
-Bundle-Version: 3.5.600.qualifier
+Bundle-Version: 3.5.700.qualifier
 Bundle-Activator: org.eclipse.update.internal.configurator.ConfigurationActivator
 Bundle-Vendor: %providerName
 Bundle-Localization: plugin
-- 
2.49.0

Further information are available in Common Build Issues - Missing version increments.

[vogella]

LGTM

[github-actions]

Test Results

 1 758 files  ±0   1 758 suites  ±0   1h 24m 43s ⏱️ - 6m 34s
 4 173 tests ±0   4 149 ✅  - 1   23 💤 ±0  1 ❌ +1 
13 119 runs  ±0  12 949 ✅  - 3  167 💤 ±0  3 ❌ +3 

For more details on these failures, see this check.

Results for commit 7b59656. ± Comparison against base commit 86aa0ac.

♻️ This comment has been updated with latest results.

[vogella]

@laeubi looks like this adds additional warnings (for example The type IPlatformConfiguration.IFeatureEntry has been deprecated and marked for removal) to the build and fails the quality gate. Can you have to look? IIRC mark for removal should be done in M1

[laeubi]

@vogella this is JDT bug:

eclipse-jdt/eclipse.jdt.core#3402

so we can not really do much than to accept the new warnings and hope for the best :-)

[vogella]

@vogella this is JDT bug:

eclipse-jdt/eclipse.jdt.core#3402

so we can not really do much than to accept the new warnings and hope for the best :-)

In this case I suggest to merge

(I assume this will update also the quality gate and future PR will use the new warning number created by this JDT bug ).

[vogella]

Can this be merged?

[HannesWell]

Could you please extend the deprecation note a bit.
We discussed this topic a while ago at the PMC, but I haven't had the time to send the note around yet.

[HannesWell]

Suggested change

	@Deprecated(forRemoval = true, since = "2025-03")
	@Deprecated(forRemoval = true, since = "2025-03 (removal in 2027-03 or later)")

[HannesWell]

Suggested change

	@Deprecated(forRemoval = true, since = "2025-03")
	@Deprecated(forRemoval = true, since = "2025-03 (removal in 2027-03 or later)")

[merks]

It's 2025-06 now...

[laeubi]

I hereby grant anyone interested in this change to apply whatever seems suitable... I just wanted to make it for removal now its pending for month due to different things and the build constantly fails some validations that I'm not sure I want to really invest more time here.

[vogella]

@HannesWell I dislike the additional meta-data request.

The PMC might decide to reduce or extend the API deletion period so putting the deletion period in comment seems wrong to me.

If you insist I can update this PR (if I can update @laeubi PR) or send a new one but I think the comment is not a value add.

[vogella]

Update here: #1867

[HannesWell]

I dislike the additional meta-data request.

The PMC might decide to reduce or extend the API deletion period so putting the deletion period in comment seems wrong to me.

In my opinion a once set, a deprecation period should not be shortened under normal circumstances, because downstream consumers might rely on it. If it's extended that also covered by the proposed change, as it has the or later suffix.
The main motivation is that probably not many downstream users are aware of the exact deprecation policy of Eclipse (TLP). So this additional text is intended to make them aware and set expectations in both directions: They can expect it stays until the specified date but also have to expect it's gone afterwards. And better awareness of the situation by more people is IMO better.

But anyways that's not yet a rule as it was not yet officially announced. I'll try to do that soon and also apply the update as you mentioned in: #1866 (comment) Thanks for the pointer.

[vogella]

Done via #1867