[BUG] Publish version/release on pkg.go.dev

[lcheylus]

I'm trying to package gh-dash for OpenBSD to import it in the official ports tree.

The port infrastructure on OpenBSD for Go projects needs to get version/infos from pkg.go.dev => get MOD_NAME and latest published version MOD_VERSION.

On pkg.go.dev, these infos are not up to date => https://pkg.go.dev/github.com/dlvhdr/gh-dash

$ go list -m github.com/dlvhdr/gh-dash@latest
github.com/dlvhdr/gh-dash v1.2.3

Please could you published the latest version v4.1.2 on pkg.go.dev and for each future release ?

[lcheylus]

See https://go.dev/doc/modules/publishing to publish your module on https://pkg.go.dev

[Omnikron13]

I believe the PR #393 I just submitted is the correct way to get those systems to kick in and pull the latest. Can't say I've delved into anything v2 and beyond tbh, thinking about it.

(On another note; does anyone else think the sheer number of specific imports across so many files is a bit of a smell?)

[dlvhdr]

I'm not that familiar with how go manages packages. When I bump a major version will I need to update all those imports again?
Im using go-releaser, maybe it can do that for me?

[Omnikron13]

Honestly, they made a bunch of changes after I first tried the language out on a couple toy projects and returning to it to see how it has come along just recently. The whole packages deal is in that gap, but as I understand it for backwards compatibility you don't specify /v1, but for every major version past /v2 you are meant to include and bump it.

There are other options to what I did tbh; you could also include version 1 as a dependency in go.mod and then you don't need to have that for anything that hasn't had breaking changes and so is technically still version one compatible. This would get very fiddly very fast. =P

Does come with the advantage that you can choose to keep supporting older versions with feature and/or bug updates and pushing new minor/patch tags more easily (kinda). Probably only ever worth bothering with if you're writing something with LTS versions, or that people on certain more glacial distros, other OS entirely, etc. have to use.

Can't help you on the go-releaser question tbh as I have no idea what that even is. I'm not even sure that this might not have been possible with go mod or one of the other subcommands; I just carefully ran a bunch of find/replace regex.

I will note as well though that there were an awful lot more specific dependencies on sub-packages and sub-sub-packages than I expected going in. It's very neat on disk and in the imports list, but then you have a bunch of unqualified identifiers in the code itself. It's a style matter ultimately I'm sure, but I'm not sure personally having everything so intimately aware of the internals of everything else is that important, and being able to refer to table because github.com/dlvhdr/gh-dash/ui/components/table is imported into the current namespace isn't necessarily something I'd consider great vs being verbose and structuring things so you have to refer to ui.Components.Table or w/e.

Ultimately I guess it's a question of how you like to view things; should foo.go know what a 'table' is itself? Should it know what a 'component' is, and understand it as something that isn't always tightly bound to it's understanding of what 'ui' is? Would it be better or worse for it to have an interface-level understanding of what a 'component' might be, and rely on that?

To be clear, I'm staying as far away from the notion that the flatter approach I'd typically at least begin with is a better approach in any way as I possibly can. In fact, my official position is that I'm lazy and this looks exhausting to me. =P

[Omnikron13]

I should definitely also point out that Go, of course, has opinions on how the versioning should all be approached: Go Modules: v2 and Beyond

[dlvhdr]

Hmm seems like I need to publish a new major for this to take effect.
I will take a look at this later

[lcheylus]

@Omnikron13 You're right: to fix this issue, /v4 must be added in module paths. Thanks for your PR.

@dlvhdr I don't know if it's possible to update the module version with goreleaser when you are bumping a major version for the project.

I think you only need to publish a new release (v4.1.3 or v4.2.0) with this fix to publish it on https://pkg.go.dev

[lcheylus]

With the latest release, the gh-dash version is now correctly published on pkg.go.dev => https://pkg.go.dev/github.com/dlvhdr/gh-dash/v4

$ go list -m github.com/dlvhdr/gh-dash/v4@latest
github.com/dlvhdr/gh-dash/v4 v4.3.0