This const isn't referenced outside of the pkg/internal/apis/certmanager/validation package. I think it should live in there as an un-exported const (or alternatively just hardcoded as the message in the call-site, which has the side effect of forcing us to write it out explicitly in test cases too, so we know if the message has been changed unintentionally)

I thought that in this case there is no harm in exporting this const and having all the future warnings in the same place would help us with consistency of the wording and naming + make it easier to change the warning text (i.e if we later want to add a version at which this field would be removed).
If anyone was actually parsing these warnings, I'd rather them use the const, then hardcode strings.

My concern is that if we start treating this as an API surface, it makes minor re-wording/edits harder in future (e.g. if we ever want to change this text).

I don't think we'd want to encourage people to parse this text, and it seems like it is harder for us to read the code that's actually emitting these warnings if there's a cross-package reference.

If this is to be exported and parseable, what's the versioning story here?

If this were more akin to the reason field on a condition (i.e. short, all one word, etc) then I'd definitely agree that there's value in having them exported. This seems more akin to the 'message' field on a condition, which is explicitly designed to be human readable.

As far as I'm aware, k8s itself doesn't treat warning messages as part of its API surface and does not advise building automation on top of parsing these strings

Good point about versioning, I didn't think about that.

I guess because these warnings would be returned to whoever applies the yaml (rather than just apearing in the logs), I thought it'd be nice to have them consistently worded, which might be easier achievable if they are all in the same place vs a bunch of hardcoded strings across the codebase.

👍 re consistency - what do you think about just moving them to where they are actually used (unexported to convey they shouldn't be depended upon/parsed), but keeping them as consts for consistencies sake? I just think being in an 'api/' package insinuates it forms part of our API (and thus can be depended upon in a similar manner to other parts of our API)

I think I agree that this could be unexported. There's no reason we couldn't make it exported later if we felt a need for it.

I also think it makes sense to move it to where it's used and remove the new file.

Thanks for the comments!
I've made the warning value unexported.
I did still put it into a file of its own in the internal validation package because I felt like this might help with the consistency of any future validation warnings that we might want to add- happy to be convinced otherwise.