Skip to content

Conversation

@russoz
Copy link
Collaborator

@russoz russoz commented Dec 3, 2025

SUMMARY

The code has special provisions for monit 5.18 and older - and that version was released in 2016.

ISSUE TYPE
  • Feature Pull Request
COMPONENT NAME

monit

@ansibullbot
Copy link
Collaborator

@ansibullbot ansibullbot added feature This issue/PR relates to a feature request module module plugins plugin (any type) labels Dec 3, 2025
@russoz russoz changed the title monit: deprecate support for monit <= 5.18 [WIP] monit: deprecate support for monit <= 5.18 Dec 3, 2025
@ansibullbot ansibullbot added the WIP Work in progress label Dec 3, 2025
@russoz
Copy link
Collaborator Author

russoz commented Dec 3, 2025

It looks like this is going to take longer than I had foreseen, so may be bump the deprecation to 14.0.0 instead of the 13.0.0 I am proposing.

I am thinking maybe in rewriting (some, if not all of) the unit tests using uthelper first, then coming back to this PR to make the adjustments. @snopoke WDYT?

@snopoke despite our conversation in #11245 (comment), it occurred to me that there is no specific feature in the module supporting versions of monit, except for that -B parameter that seems to have been added after monit 5.18. In that case, I think we can strongly recommend that a more recent monit is used, but there is nothing preventing them from using it with 5.19, 5.20, etc..., so I see no point in make a claim that we are not enforcing - we could enforce it, but I see little benefit in doing so, I reckon it would be perceived as us just being unnecessarily picky.

All that means that I am probably going slower on this thing.

@felixfontein felixfontein added check-before-release PR will be looked at again shortly before release and merged if possible. backport-12 Automatically create a backport for the stable-12 branch labels Dec 3, 2025
@snopoke
Copy link
Contributor

snopoke commented Dec 3, 2025

It looks like this is going to take longer than I had foreseen, so may be bump the deprecation to 14.0.0 instead of the 13.0.0 I am proposing.

I am thinking maybe in rewriting (some, if not all of) the unit tests using uthelper first, then coming back to this PR to make the adjustments. @snopoke WDYT?

@snopoke despite our conversation in #11245 (comment), it occurred to me that there is no specific feature in the module supporting versions of monit, except for that -B parameter that seems to have been added after monit 5.18. In that case, I think we can strongly recommend that a more recent monit is used, but there is nothing preventing them from using it with 5.19, 5.20, etc..., so I see no point in make a claim that we are not enforcing - we could enforce it, but I see little benefit in doing so, I reckon it would be perceived as us just being unnecessarily picky.

All that means that I am probably going slower on this thing.

That all sounds reasonable to me. I wasn't aware of UTHelper, looks like it would be useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport-12 Automatically create a backport for the stable-12 branch check-before-release PR will be looked at again shortly before release and merged if possible. feature This issue/PR relates to a feature request module module plugins plugin (any type) WIP Work in progress

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants