search

deckarep / golang-set

A simple, battle-tested and generic set type for the Go language. Trusted by Docker, 1Password, Ethereum and Hashicorp.
Other
4.15k stars 274 forks source link

Update the `latest` tag on github to point to v2 series? #89

Closed jeffwidman closed 2 years ago

jeffwidman commented 2 years ago

I've been watching this repo waiting for a tag to be cut for the new generic-based code.

Today I finally realized that a version was cut nearly a week ago... but I never saw it because https://github.com/deckarep/golang-set/releases points to v1.7.1

However, the newest released tag is actually https://github.com/deckarep/golang-set/releases/tag/v2.1.0

Can you update that latest release to show v2.1.0 as the latest?

That will also likely cut down on folks reporting bugs against the v1 series, not realizing they should switch to the v2 series...

deckarep commented 2 years ago

Good call!

I’ll update tomorrow as I’m out on business today.

Thanks for the watchful eye…totally spaced it on the release update!

deckarep commented 2 years ago

@jeffwidman - sorry for the delay on this...I posted the new release. Please look it over and let me know if you see any further issues.

Big thx!

jeffwidman commented 2 years ago

Looks great, thanks!

deckarep commented 2 years ago

@jeffwidman - it's been a few weeks and according to https://pkg.go.dev/github.com/deckarep/golang-set/v2 so far not a single repo has imported the v2 generics code.

Specifically: https://pkg.go.dev/github.com/deckarep/golang-set/v2?tab=importedby

I'm sure not everyone will be quick to adopt Go 1.8.0 (with generics support) but I would have figured a few folks by now would have pulled in the V2 code from this repo.

Do you perhaps see any other publishing issues with how this got released which may be preventing some adoption of this lib?

jeffwidman commented 2 years ago

I'm not really surprised... there's a a few things going on:

I think the only real thing you could do is improve the messaging... go get -u isn't going to realize there's a v2 version, so it'll only pull the latest v1 version. And the v1 code works perfectly fine, so they won't realize problems unless they want to add a feature, then they'll find this.

If you want to speed up the messaging, you could drop a final release of the v1 series which includes the Deprecated: annotation for the couple of methods we removed... ie: 

// Deprecated: Use NewSet(vals...) instead.  Note that this will require bumping to the v2 release series, which leverages generics for greater type safety.
func NewSetWith...

Or something like that... because some projects have linters that complain about deprecated code, those projects will get notified by their CI systems and switch.

deckarep commented 2 years ago

Everything you said makes complete sense I was mostly thinking along these lines as well.

Im also guilty of waiting for patch releases to let the dust settle when migrating. I was concerned that I overlooked something but I also know that 1.18 is so new and any serious project isn’t going to just jump and update all deps.

For what it’s worth I really appreciate your feedback, API inputs and early adopting on migrating to the generic release on this package.

Updating the deprecation notice also sounds like a good idea and a step in the right direction.

jeffwidman commented 2 years ago

No problem, flipping to v2 was a great project to cut my teeth on generics for the first time with a practical example.

For implementing the deprecation markers, you can see an example here: https://github.com/golang/go/pull/51961/files

You may want to wait til 1.19 drops though, as that way you don't annoy folks who aren't yet able to flip to 1.18/v2 until they've had a little more time to bring the rest of their stuff up to date...