Bump golang.org/x/text from 0.22.0 to 0.23.0

[dependabot]

Bumps golang.org/x/text from 0.22.0 to 0.23.0.

Commits

• 566b44f go.mod: update golang.org/x dependencies
• d5156da collate/build: do not use println in tests
• 221d88c x/text: fix scientific notation by removing extraneous spaces
• b18c107 internal/export/unicode: change C comment to mention unassigned code points
• 835f8ac language: use a more straightforward return value
• ae68efb internal/export/unicode: add CategoryAliases, Cn, and LC
• 518d9c0 all: upgrade go directive to at least 1.23.0 [generated]
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[johnkerl]

@dependabot rebase

[johnkerl]

https://github.com/johnkerl/miller/actions/runs/13700263974/job/38312024257?pr=1767

go: golang.org/x/[email protected] requires go >= 1.23.0 (running go 1.21.13; go.mod sets toolchain go1.21.13)

I don't want go accept a PR that makes Miller's minimum Go version 1.23 (latest is 1.24) -- Miller has users on LTS operating systems etc. and I prefer to remain trailing-edge on the Go version.

cc @skitt I seem to recall some level of backward Go-version compatibility but I realize I never acquired a good rule of thumb for how old a Go version to insist on -- can you advise?

[skitt]

cc @skitt I seem to recall some level of backward Go-version compatibility but I realize I never acquired a good rule of thumb for how old a Go version to insist on -- can you advise?

I tend to review dependabot PRs on their merits, same as any other; in this case, the only potentially relevant fix in x/text seems to be this scientific notation fix, and I’m not sure it’s even relevant for Miller. If it isn’t, then there’s no downside to just closing the dependabot PR, problem solved.

As far as the more general question is concerned, Go is backward-compatible, yes, but that means that newer compilers continue building older code without change, which doesn’t help here. The problem with older Go releases is that the Go project only supports the last two releases, and there are regular security fixes — so an older Go compiler (1.22.x or older now) is liable to build binaries with known vulnerabilities. Some projects enforce that by bumping their Go language level even though they don’t use any of the new Go features, just to enforce the use of a supported compiler; I understand the reasoning but it makes life complicated for projects like Miller.

I don’t have a good rule of thumb in this instance. Repology’s Go page shows which distributions have which version of Go, and that shows that a lot of distributions have 1.22 or older (and thus probably a not-so-great security story around Go, but that’s a tough nut to crack). However I tend to think that this is only a blocker for distribution updates of a Miller package: a distribution package can only be built with packages in the distribution, so a Go project requiring a newer toolchain can’t be packaged. People interested in building the latest release of Miller themselves can hopefully figure out how to install the latest toolchain themselves too, although I do recognise that that’s not a great story (in comparison to go install github.com/johnkerl/miller/v6/cmd/mlr@latest; it would be great if just worked, regardless of the version of Go provided by the system).

Note that the Go toolchain itself is solving this problem, for end-users: newer releases know how to download even newer releases when necessary, so once everyone has a new enough release (1.21 or newer, IIRC), this won’t be a concern except for CI and packagers (where downloading a newer toolchain isn’t acceptable).

[johnkerl]

Thank you @ski!! 🙏

[johnkerl]

#1765 (comment)

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.