Update dependencies, actions steps, and usage for v2-maint

[meatballhat]

What type of PR is this?

• maintenance

What this PR does / why we need it:

Like the title says, to keep up with [gestures wildly in all directions].

Which issue(s) this PR fixes:

N/A

[dolmen]

@Juneezee @meatballhat This PR should not have been submitted as is, and should not have pass review. A single commit that contains changes to go.mod, go.sum, .github/workflows/ and testdata/expected-doc-full.man is just poor quality, and could even have been the vehicule for evil things (thinking about xz).

I'm definitely worried about the maintenance of this project if such poor work pass validation. This project is now a huge danger to the Go ecosystem.

Cc: @dearchap

[meatballhat]

@dolmen Hello! I think I need some help understanding the risks 🤔

[dolmen]

As a user of this module who tries to keep track of changes in dependencies before upgrading (and not blindly apply Dependabot changes), I appreciate to be able to read the Git history and understand what is happening.

Maybe I just would like to see:

• more verbose commit messages. In this case, it would have been worth mentioning why the file in testdata had to be modified
• less unrelated changes in a single commit: the workflows changes are independent of the Go dependency upgrade, so there should have been 2 separate commits

[dearchap]

@dolmen I fail to understand why as a user of this library this matters to you at all. I mean sure most issues/PRs could do with better descriptions etc but that would be from a point of a developer who isnt familiar with the codebase/workflow at all. In general all the devs on this repo strive to maintain good practices and we generally make sure everyone is one same page. Reg dependencies we try to be minimally dependent on external libraries as this library is a framework on top on which cmd line tools(in conjunction with other packages) are built on. Of course we have to keep up to date with latest go versions more for security fixes than for any go version specific feature. We cant just keep the project stagnant by using a 1-2 year old go version for workflow. if you have any issues with these approaches I highly suggest you fork this repo and maintain it as per your requirements

[abitrolly]

I understand of joy of reading well written changelogs and commit messages, but that doesn't help on hard days.

@dolmen yes, without people like you asking, the quality of commit messages will be a bit relaxed. However, if you want to make the change, some stuff from https://handbook.gitlab.com/handbook/values/#assume-positive-intent might be helpful.

I guess you don't have time to chase the maintenance of yet another package, and that, of course, brings frustration. But if you consider this to be an opportunity to learn about Go and spend some time socializing for good, then maybe asking your questions like "why the change to tests is needed" directly, will make your next day brighter and our common code more secure.

[dolmen]

My frustration comes from the fact that, at work, I have to maintain alone about 30 services which depend on urfave/cli. I'm not yet done on migrating from v1 to v2, and now v3 is there. Of course that is just one of the dependencies I have to monitor (I have submitted #1847 a few months ago to reduce that load, and I still have to port that to v3). So I'm probably too touchy about commit quality when I review change before upgrading my dependencies. But I realize I have been too far in complaining on a closed PR: none of this frustration should be of the concerns of the maintainers.

So I apologize for having gone much too far in raising my concerns about readability of commits here. I should just have kept those to myself. A merged PR is not the right place to push for higher standards, and I should not have involved so many people.