Restructuring Go modules version approach

[johnweldon]

As discussed in #502 and #467

What do you think @cpuschma ?

[cpuschma]

I suggest the following steps:

1. In the next 2-3 releases warn people that the v3 folder will not be updated in the future
2. Do not mirror the v3 folder anymore (except for vulnerability updates)
3. Discard the v3 folder in a new major release. Due to the major release, breaking changes are justifiable

To be honest, I've been thinking about abandoning the current design lately. I've been prototyping my own LDAPv3 implementation in Go in my spare time to familiarise myself with the specification and implementation with a more generic concept in mind, using the structs for requests and responses and implementing a Marshal and Unmarshal function per struct. You could use this design to be extremely flexible with almost no overhead when implementing a new feature. You could also write a simple LDAP server because of the bi-directional Marshal/Unmarshal design. One could implement a compatibility layer so that most functions stay the same for developers.

[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.