On 2017-09-12 6:45 PM, Patrick M. Galbraith wrote:
Darren,
I agree with this as well, with the exception of 4 and 5, keeping 5.0 "pure" to
the new way of doing things.
I very much agree, pure is best. I only suggested 4 and 5 as half-hearted
options because I knew some projects in our community liked to do things like that.
For releases, I think I want to understand what this will mean. Sooner or later,
a release shows up in as a distribution package, installed on the OS, and I want
to know what the way of communicating that to the users and vendors so
expectations are met. That's another question of "how do we handle that?" and
"how do we inform an OS packager/vendor, what to do?
Thank you for the great discussion!
Based on my experience, the fact the major version number is being changed from
4 to 5 will communicate a lot by itself.
Many software projects use semantic versioning, see http://semver.org for a
formal definition adopted by SQLite among other projects, and all the common
package managers and package repositories understand it.
Generally speaking, if the first number in a dot-separated version number is
incremented, it is treated as being a major version, and then any version
numbers having that first part in common are considered minor versions of the
same major.
Given the default behavior of package managers, any users performing a generic
"keep me up to date with all the patches and bug fixes" should receive the
latest version sharing the major version they already have, and going to a new
major version would require a more explicit "install this separate thing" on the
user's behalf.
Tangentially to this, this DBD::mysql is a CPAN module, CPAN conventions can
also be followed by the package managers.
As for giving explicit communication to repository maintainers eg Debian and
CentOS and whatever, I think that's a matter of direct human communication.
Perhaps have the person managing the packages for MySQL itself handle it.
This all being said, for people using the CPAN clients, I believe their rules
are simpler and they simply always get the highest numbers, ignoring major/minor
stuff, except for Perl itself.
For the sake of CPAN clients, another possible alternative is to fork the
namespace. The current DBD::mysql name either means the old legacy version or
the new better version, and then you pick a new name for the complement.
A semi-relevant example of this is DBD::SQLite back in 2003 when SQLite 3 came
out. In that case, SQLite 3 was a complete break from 2, neither could read the
others' files. They renamed the old DBD::SQLite to DBD::SQLite2 (or some such)
which was the one for SQLite 2, and the plain DBD::SQLite name then meant SQLite
3. That being said, all the SQLite 2 ones were 0.x versions, and then version
1.0 was the first SQLite 3 version. So the fact that prior to the break the 0.x
semantics of (anything might break) made the decision easier.
I think the decision then of which MySQL client keeps the old name depends on
what you want to happen when users simply "get the latest" without testing. If
the latest features and fixes stay with the old name, then the name for the
legacy fork could be DBD::mysql::LegacyUnicode 4.044 AND DBD::mysql jumps to
5.0. If the latest features go to a new name, then you could have eg
DBD::mysql2 version 1.0; it would be like a fork, but its official. The former
approach will mean users with broken code will have to update their code to the
new module name but won't have to fix their Unicode. The latter approach means
people wanting the new stuff change the driver name they call.
Another option that lets you keep the same name for both but requires other
parts of the ecosystem to at least update some code, is you stick with the
originally discussed 4-5 move, and other middleware modules add explicit
internal code paths for "if DBD::mysql version >= 5 then expect correct Unicode
behavior and otherwise expect and compensate for broken Unicode"; I expect
DBIx::Class and friends will all add such checks anyway, short of hard requiring
the new version.
Basically, its all about tradeoffs, who you want to do what work and who you
want to be able to do zero work.
-- Darren Duncan
