Restructuring Go modules version approach

[johnweldon]

As discussed in #502 and #467

What do you think @cpuschma ?

[cpuschma]

[t2y]

I agree with @cpuschma migration plan. I will help with testing/verification if needed.

[cpuschma]

@johnweldon What do you think about both points?

[johnweldon]

I'm in agreement.

…

On Thu, Apr 4, 2024, 2:41 PM Christopher Puschmann ***@***.***> wrote: @johnweldon <https://github.com/johnweldon> What do you think about both points? — Reply to this email directly, view it on GitHub <#503 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMOWT5VIOEAYC2A2EHZATY3XCIBAVCNFSM6AAAAABFTY5APKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TAMJUHAYDG> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[maxb]

I think there's a simpler option with a better outcome:

1. Delete the v3/ folder
2. Modify go.mod and examples_windows_test.go in the root directory to include /v3 in the module/package path
3. Make the next v3.4.x tag

This solves the problem of having two copies of the code immediately, should be transparent to users, and so doesn't require a major version bump.

The reasons it should be transparent to users are:

A) For Go modules users, this is just shifting between two different permitted represenations of github.com/go-ldap/ldap/v3. When the Go modules code reviews the contents of v3.x.x Git tags, in some of them it sees v3/go.mod with the correct module path, and in some just go.mod. Both are permissible, and go get is happy to upgrade and downgrade across the change without issue.

B) For legacy GOPATH users, if any still exist, it's still transparent, as Go versions 1.9.7+, 1.10.3+, and 1.11 added transitional support for consuming code that has migrated to modules from GOPATH mode, even when it has a v2+ major version. Since go-ldap itself has since moved on to requiring Go 1.14+ anyway, we can depend on users having this functionality.

In this way, we can simplify away the additional copy of the code immediately, without needing a user-visible deprecation timeline.

[johnweldon]

Hopefully we can experiment with this and validate that it'll work as expected without breaking users build and deployment processes.

I won't have time to work on this soon, but I welcome anyone else trying it out on a throwaway repo and validating that this approach would be safe.

[maxb]

I've done some testing with a fork at github.com/maxb/ldap, in which v3.4.888 is just updating to the forked names, and v3.4.999 is the proposed change applied. The scenarios I could think of worked as expected.