Change default namespace to MySqlConnector

[bgrainger]

This reopens #189.

Poll: Please vote 👍 or 👎 on this issue if you'd like to see this implemented (or not).

In the past, MySqlConnector was simply trying to become a replacement for MySQL Connector/NET, and cloning its API (down to the namespace) seemed like an easy way to displace it, by providing a simple upgrade path. But as the list of known Connector/NET bugs and edge cases has grown, MySqlConnector has chosen to become incompatible in an increasing number of ways. Thus it's much less true that a user can upgrade by just changing their NuGet package reference and none of their code.

Additionally, MySqlConnector is now pushing the API forward (async, batching, bulk copy, etc.) beyond what Connector/NET supports. It makes sense for these new features (that are "defined" by MySqlConnector) to be in their own namespace (instead of in a namespace where they might one day conflict with Connector/NET if it ever implemented those classes slightly differently).

Finally, while it's possible to use both MySqlConnector and MySql.Data in the same project, it's difficult and it impacts all consumers of that project: mikependon/RepoDB#375 (comment).

Pros

• Dedicated namespace for all new MySqlConnector features
• Makes the NuGet package name match the primary namespace
• Legacy APIs (such as MySqlHelper) could move out of the main namespace
• Easier to use both MySqlConnector and MySql.Data in the same project (possibly niche use case, but useful for benchmarking)
• Easier to find API documentation for this library (e.g., with Google)
• Makes it clear that "MySql.Data" is unrelated to this library (as that would no longer appear in the code)
• Makes it clear which library is being used when a stack trace is posted (e.g., on Stack Overflow or a GitHub issue)

Cons

• Breaking change for all current users
• Harder to upgrade for new users
• Effort required to update code, documentation, open PRs to important downstream projects
• Less likely to capture new users by showing up in Google results for MySql.Data.MySqlClient

[dustinsoftware]

a user can upgrade by just changing their NuGet package reference and none of their code.

So long Mysql.Data, it was nice while it lasted.

[mikependon]

This library has proven its worth and the user will use it accordingly (even with Namespace change). If I am to weigh the PROS and CONS above, I would gladly like to choose the benefits of the PROS above. My use case of having an ORM that could abstract both library is quite unique (so for others), but it would help me a lot when it comes to maintainability, operation-wise and simplicity. The use-case of combining both libraries (i.e: MySql.Data and MySqlConnector) is a quite good use-case in which you do not limit the users to explicitly remove the other. I would suggest it will start from here unless Oracle decided to not coincide on this tool.

[nvivobume]

My 2 cents in favor of this change:

• This library has gained enough traction that nobody will stop using it because of this change
• Most projects use some library like EF or Dapper in a way that the change would be restricted to a few places only
• A search/replace can easily migrate a project to the new namespace

This is a change that should bump the version to 1.0 or even 2.0.

[penguinawesome]

+1!