just reduce/pretty code and set go version to go1.16+ in go.mod

[alimy]

• set go version to go 1.16 in go.mod

  because ioutil.ReadFile(...)/ioutil.ReadAll are deprecated since go 1.16 so use minimum go version is set to 1.16(now go is go1.20+, so use go1.16+ is well)

• reduce and pretty some source code

  no need // +build go1.8 build tag because go version minimum support is go1.16+

[uvulpos]

Looks good to me

[BenKnigge]

Why upgrade the go version? It should be set as low as the code allows. Some people are stuck working on older version of go and are unable to upgrade. The library should not be upgraded unless it's absolutely necessary.

[uvulpos]

I would release a legacy version of sqlx and then just stick by the lowest still maintained version of go. I think this is necessary because this way we make sure our code doesn't get any security flaws by the go compiler. If companies don't use their budget to upgrade or make their go version really dependent on one old go version, this shouldn't affect newer projects in terms of security. Also, never versions of go attracts more maintainers.

[uvulpos]

some example go.mod files:

• Fiber's go.mod
• Gorilla's go.mod
• Segmentios Kafka's go.mod

[BenKnigge]

It's going to be compiled with whatever version of go is installed on the system of whomever is using the library. The oldest version of the go compiler still supported for security upgrades is 1.19. If we were adding functionality dependent on 1.19 I would support upgrading it but upgrading it just to upgrade while breaking compatibility I do not support. I've worked at companies in the past where upgrading the compiler requires an extensive review process.

Edit : I've worked on a project very recently where the compiler is pinned an 1.18.6 If the policy was to set this to the oldest supported which is 1.19 I would not be able to use this fork at all.

Edit 2 : The lowest version possible mean that the project is available to the widest audience.

[uvulpos]

Ok, you convinced me 🙂

[BenKnigge]

@uvulpos If you feel strongly about merging this, let's create an initial release, the origin repo's last tag was v1.3.5, let's create a release or tag with v1.3.6 after that if you merge this make it 1.4.0 and if we upgrade the required compiler again bump the to 1.5.0 etc ...

[BenKnigge]

@uvulpos my argument is kind of moot since this repo has three dependencies and the the mysql drive update has a go mod requiring go 1.18 since that dependency is 1.18 that minimum would propagate up to this project.

[BenKnigge]

I don't see the need for this. I feel that the library should continue to be compatible with the oldest version possible.

Edit: I'm not opposed to this if we were adding new functionality that would require an upgrade or if a new version of go were to drop inclusion of the deprecated functions.

[uvulpos]

I would not say I feel strongly about merging it, I just don't have had these issues jet what you described.

For us, we announce to our customers that there is a new go version, we write a technical task for it, put it in the sprint and there we go. Mostly they appreciate it, and it's part of our maintenance budget.

I see it as a clash between the argument of attracting new maintainers / getting work better done / writing better code and maximum compatibility. Here we will certainly become philosophical on what's more important.

For me: I doubt that if projects don't update their go version, they will upgrade their dependency versions. So that's why I offered a compatibility release. Besides, I think it should not be the community's responsibility to support these ancient projects when companies skimp on their budgets.

I'm still open to keeping the required version low, but I would say 1.16 is a good minimum requirement. Maybe even 1.18

[BenKnigge]

I have approved, you can merge when you are ready.

[uvulpos]

We should come to an agreement instead of just doing something. But for now on just leave it until we have a first release

[BenKnigge]

Since we already have a dependency that has a dependency of 1.18 I now agree that this pr bumping the minimum go version to 1.16 will not be an issue.

[alimy]

I agree upgrade go minimum version support to go1.18, maybe will optimize some export interface by sqlx use go generic in future and it is supported sine go1.18.

Since we already have a dependency that has a dependency of 1.18 I now agree that this pr bumping the minimum go version to 1.16 will not be an issue.

also agree for it, this pr just some code pretty and upgrade go version is not necessary. Maybe we can upgrade go version
when optimize some logic in sqlx that need to get the minimum go version support(eg: go generic support).

I don't see the need for this. I feel that the library should continue to be compatible with the oldest version possible.