Considering v1.7.1

[methane]

After v1.7.0 was released, #1402 was merged.
Before start merging large/backward incompatible features, how about releasing v1.7.1?

If go, I want to fix #1355 in v1.7.1 too.

@shogo82148 How do you think?

[sjmudd]

Good morning @methane.

Thanks for looking at this. If you go ahead, and related to discussions perhaps the documentation should favour the use of https://pkg.go.dev/github.com/go-sql-driver/mysql#Config rather than direct configuration of the DSN directly?

You wrote:

And I don't want to recommend to use DSN. We need to move much documentations from DSN readme to Config object.

I realise this is a time-consuming process and may require multiple changes but at least add a comment immediately after the Usage section in https://github.com/go-sql-driver/mysql, indicating this preference. As things stand it's quite easy to overlook this and for the simplest DSN configuration it seems better/simpler to just create a DSN manually which you indicate you would like to avoid. So a simple change there in bold saying "We recommend usage of use the mysql.Config struct and usage of Config.FormatDSN() to generate the DSN as this both simplifies DSN generation and ensures the created value is correct even in more complex cases" or similar would be more visible and lead people in that direction.

As a single paragraph in the right location it should do most of what you need.

[methane]

For simple configuration, using DSN and writing DSN manually is OK.
I recommend to use Config for complex configurations.

And I don't recommend to use Config.FormatDSN() at all. We do not guarantee that FormatDSN() always produce round-tripping, correct DSN.
When using Config object, just pass it to OpenDB().

[sjmudd]

oh, apologies. I misunderstood the way you wanted to suggest this to be done, but thought I understood the suggested usage was to use the Config struct and then open the database based on that, rather than generate the DSN manually.

[shogo82148]

Before start merging large/backward incompatible features, how about releasing v1.7.1?

@methane It sounds good.

[dolmen]

@methane wrote:

And I don't recommend to use Config.FormatDSN() at all. We do not guarantee that FormatDSN() always produce round-tripping, correct DSN.
When using Config object, just pass it to OpenDB().

Unfortunately the documentation for Config.FormatDSN() says:

FormatDSN formats the given Config into a DSN string which can be passed to the driver.

The documentation of Config should link to NewConnector which is the step to use OpenDB.