Closed merks closed 5 months ago
Great to solve this and identify that it is safe to make platform a root feature.
With the general changes here, no EPP feature or product IU locks in a specific version of any non-EPP IU. As such, in principle, any project, or even the staging repository, can directly provide updates to any of the EPP installations.
@jonahgraham
FYI, now that the EPP IUs don't lock in specific versions of non-EPP IUs, I have updated the product catalog generator to produce staging versions of the products:
With the short release cycles, and the Platform's light-weight milestones, it's increasingly problematic that EPP installations cannot update to a more recent build of the Platform that contains a fix to some problem. If there is a fix in the Platform, one must wait for an EPP milestone or release to be able to update to that release. E.g., this issue is a glaring recent reminder of how annoying that restriction can be:
https://github.com/eclipse-platform/eclipse.platform.ui/issues/1674
The constraints can be relaxed by using
installMode="root"
in each *.product.To prevent the feature from being uninstalled, the feature.xml can specify a requirement with a very permissive range:
I have tested creating such an installation, and it finds no updates initially.
until this site is added:
https://download.eclipse.org/eclipse/updates/4.32-I-builds/
and then updates are available:
And it's not possible to just uninstall the feature without warning
and even if you do that, it's not actually uninstalled
Also, the org.eclipse.platform feature includes these two things:
So products do not need to specify those redundantly.