Some Spring Cloud Kubernetes auto-configuration classes no longer public

[breun]

Describe the bug

Some Spring Cloud Kubernetes auto-configuration classes are no longer public, which makes it unnecessarily hard to refer to them.

Sample

I have some auto-configuration code that needs to run before some Spring Cloud Kubernetes auto-configurations.

With Spring Cloud 2025.0 I could achieve that using this annotation:

@AutoConfiguration(before = {
    SimpleDiscoveryClientAutoConfiguration.class,
    CommonsClientAutoConfiguration.class,
    KubernetesDiscoveryClientAutoConfiguration.class
})

org.springframework.cloud.kubernetes.fabric8.discovery.KubernetesDiscoveryClientAutoConfiguration seems to be have been renamed to org.springframework.cloud.kubernetes.fabric8.discovery.Fabric8DiscoveryClientAutoConfiguration with Spring Cloud 2025.1.0-M4, which in itself is not a problem, but the new class is no longer public, so I cannot reference it anymore from my code like this.

I see that some more Spring Cloud Kubernetes *AutoConfiguration classes are not public in Spring Cloud 2025.1.0-M4:

• org.springframework.cloud.kubernetes.commons.KubernetesCommonsSanitizeAutoConfiguration
• org.springframework.cloud.kubernetes.fabric8.Fabric8ActuatorConfiguration
• org.springframework.cloud.kubernetes.fabric8.discovery.Fabric8CatalogWatchAutoConfiguration
• org.springframework.cloud.kubernetes.fabric8.discovery.Fabric8DiscoveryClientSpelAutoConfiguration
• org.springframework.cloud.kubernetes.fabric8.discovery.Fabric8ReactiveDiscoveryClientAutoConfiguration
• org.springframework.cloud.kubernetes.fabric8.discovery.Fabric8ReactiveDiscoveryHealthAutoConfiguration

In order for users to be able to exclude/include auto-configurations, or explicitly order their own auto-configurations to run before or after other auto-configurations, it would be great if all *AutoConfiguration classes would be public.

[wind57]

hey!

I wrote the code that makes them non-public, and the reasoning I had in mind, was that since they are public, we can not make any changes to them when we want to. We need to wait until the next major happens...

Your use-case makes sense though. I wonder if it would work to make them back public, but leave the beans creation as non-public methods.

Let's wait for Ryan and see what he says. If he agrees to make them less strict, I will do it; though I do not like it :) We had PRs in progress for literally years, because we could not change public code...

[breun]

I think for the use cases I mentioned it would be fine to just make the @AutoConfiguration classes public, I don't see a need to make all of the bean creation methods public.

All of Spring Boot's @AutoConfiguration classes seem to be public as well.

Of course minimizing breaking changes is nice for users, but Spring Boot allows breaking changes two times per year, so I wonder why Spring Cloud wasn't able to do breaking changes for multiple years when there is at least one new Spring Cloud version per year.

[wind57]

@ryanjbaxter need your wisdom in here... thank you

[ryanjbaxter]

Yes I agree this is a good reason to make the classes public. For now we ca leave the methods non-public. Appreciate the feedback!