Release new version >2.0.0?

[mika]

Looking at https://github.com/gomodule/redigo/tags there's a strange order with version numbers:

• v1.8.2 on 2020-06-08
• v1.8.1 on 2020-05-06
• v1.8.0 on 2020-04-30
• v1.7.2 on 2020-04-30
• v1.7.1 on 2020-04-30
• v1.7.0 on 2018-12-13
• v2.0.0 on 2018-03-14(!)

So version v2.0.0 being the highest version number actually predates all the newer ones.

Debian ships the golang-github-gomodule-redigo-dev package as of version 2.0.0 (which also explains why their automated tools didn't notice that there's a "newer" version available since then).

Would it possible to release a new version as something like 2.1.0? (Otherwise Debian would have to introduce a so called epoch version, which is considered the last resort)

Thanks!

[mwf]

I just had the same question today :)

The main downside, new module github.com/gomodule/redigo/v2 should be introduced than... Which will lead to changes in client imports.
Without having it, v2.1.0 would be marked as v2.1.0+incompatible in client go.mod. Not a big deal for now, but it's pitty that one mistake leads to such ugliness )

[mika]

Is there any chance to get this fixed soonish? Asking, because if the upcoming Debian/stable release (AKA bullseye) is supposed to include a current version of redigo, this would need to be handled rather sooner than later. ;(

[stevenh]

v2 is not being developed / supported v1.X is the one which should be used.

See this PR for all the history on why we chose to do it this way: #440

[onlyjob]

Why not bump the version to 3 without changes? That should eliminate all confusion.

[stevenh]

See the conversation on #440 but in short major version bumps in gomod are painful for users :(