Fix typo in RemindingNotifier interval setter

[codingkiddo]

Fixes a typo in RemindingNotifier's check reminder interval setter.

The existing public method name setCheckReminderInverval contains a typo. This change adds the correctly spelled setCheckReminderInterval method and keeps the existing misspelled method as a deprecated forwarder for backward compatibility.

Also updated sample configuration, documentation examples, and tests to use the corrected setter name.

Tests run:

• mvn -pl spring-boot-admin-server -Dtest=RemindingNotifierTest test
• git diff --check

[cdprete]

I'm not a mantainer of the project, so my opinion here counts very little, but the fix is so trivial for whoever is using the feature that I wouldn't bother to keep the mistyped method, to be honest.

[codingkiddo]

I'm not a mantainer of the project, so my opinion here counts very little, but the fix is so trivial for whoever is using the feature that I wouldn't bother to keep the mistyped method, to be honest.

Thanks for taking a look.

I kept the misspelled setter as a deprecated forwarder because this is a public API method and removing it could break existing users. I’m happy to remove the compatibility method if the maintainers prefer a direct rename only.

[cdprete]

I kept the misspelled setter as a deprecated forwarder because this is a public API method and removing it could break existing users. I’m happy to remove the compatibility method if the maintainers prefer a direct rename only.

Understandable and, depending on the type of the API and the effort to migrate to the new one, I would have potentially done the same.
On the other end, keeping the deprecated method arises the concern about when it's safe to drop it.
In the next minor version 4.1.0? In the next major version 5.0.0?

[codingkiddo]

I kept the misspelled setter as a deprecated forwarder because this is a public API method and removing it could break existing users. I’m happy to remove the compatibility method if the maintainers prefer a direct rename only.

Understandable and, depending on the type of the API and the effort to migrate to the new one, I would have potentially done the same. On the other end, keeping the deprecated method arises the concern about when it's safe to drop it. In the next minor version 4.1.0? In the next major version 5.0.0?

That’s a fair concern.

If we keep the deprecated forwarder, I’d suggest treating it as a compatibility bridge for the 4.x line and removing it in the next major version, 5.0.0, rather than 4.1.0. Since the misspelled method is already part of the public API, removing it in a minor release could still surprise users who call it directly.

That said, I’m also fine to simplify this PR and remove the deprecated method if the maintainers prefer not to carry the compatibility API for this typo.

[cdprete]

Up to the team ;)