chore(deps): update dependencies to latest versions

[nodivbyzero]

Fixes Or Enhances

• chore: update dependencies to latest versions

• go ver. 1.23
• all dependencies to latest versions
• GitHub Action workflow with go 1.23

@go-playground/validator-maintainers

[nodivbyzero]

@deankarn Is it ok to merge this PR?

[deankarn]

@nodivbyzero no because of:

• The addition of the /vendor directory and deps within.
• Min Go supported version has been bumped from 1.17 to 1.21 which is a breaking change requiring a major version bump

[coveralls]

coverage: 74.318%. remained the same
when pulling 709e955 on nodivbyzero:upd-deps-dec-2024
into 6c3307e on go-playground:master.

[nodivbyzero]

@deankarn I've updated my PR and removed the vendor folder.
Quick question: Is there a requirement to support Go 1.17 as the minimum version?

[deankarn]

Quick question: Is there a requirement to support Go 1.17 as the minimum version?

@nodivbyzero only that if anyone is still using Go 1.17 it would/could break people existing builds if we add anything that’s not backward compatible with 1.17 which is more likely than other version bumps because thats when generics were added. I would love to recommend others update to a newer version if in this situation but possible they can’t for some reason or other reasons.

We can add more recent features though, without bumping a major version(which is a pain because of the way go versions > v1 is in the import path itself and is prolific down the dependency tree), by adding compile time directives.

I can totally be convinced otherwise though and perhaps, for a future addition, can add to the README + docs that we support up to only say 3-4 version back from the latest.

[nodivbyzero]

@deankarn Thank you for the detailed explanation.
I noticed that the last major release occurred on November 17, 2019, which was five years ago. While maintaining compatibility with older Go versions is important, addressing vulnerabilities and keeping dependencies updated is equally critical.

Here's a proposed plan:

• Notify the community via 'GitHub Discussions' about introducing a major version update cycle aligned with every three Go version updates.
• Update the README to include a compatibility plan.
• Close this PR for the time being.

What are your thoughts on this approach?

[deankarn]

@nodivbyzero it sounds reasonable, but I want to think about it for a little bit first as the one aspect that still bothers me is that bumping major versions in Go causes all package imports needing to be updated as well.

This doesn’t sound like much when it’s a single project or repo, but even I have production code that spans many repos which updating like this becomes a major chore. Maybe not with this package specifically but I have seen subtle bugs and issues arise when you miss updating one of these imports in your dependency chain also when the package self-initializes/ is meant to be a singleton. (As a personal note I very much dislike how go has done this and IMO should have relied on the mod file to specify the version and not imports…)

I have been and will continue to read about how others handle this. This is an old discussion for Rust not Go but highlight the same issues rust-lang/api-guidelines#123

[nodivbyzero]

Closing this PR in favor of the discussion at #1342