On 9/13/17 9:31 AM, p...@cpan.org wrote:
On Tuesday 12 September 2017 11:32:36 Darren Duncan wrote:
On 2017-09-12 11:05 AM, p...@cpan.org wrote:
On Tuesday 12 September 2017 19:00:59 Darren Duncan wrote:
I strongly recommend that another thing happen, which is
re-versioning DBD::mysql to 5.0.
1. From now on, DBD::mysql versions 4.x would essentially be frozen
at 4.041/4.043.
2. From now on, DBD::mysql versions 5.x and above would be where all
active development occurs, would be the only place where Unicode
handling is fixed and new MySQL versions and features are supported,
and where other features are added.
I'm fine with it. Basically it means reverting to pre-4.043 code and
continue *git* development there with increased version to 5.x. And once
code is ready it can be released to cpan as normal (non-engineering) 5.x
release.
Yes, as you say. With respect to Git I propose doing this immediately:
1. Create a Git tag/branch off of 4.043 which is the 4.x legacy support branch.
This is up to Patrick.
I agree that we can start there. I do like the discussion going on now
and want to engage all those concerned and interested and have a plan.
2. Revert Git master to the pre-4.043 code and then follow that with a
commit to master that changes the DBD::mysql version to 5.0.
If everybody agree with this step, I can prepare pull request which
revert tree to this state, plus re-apply/rebase commits which were newly
accepted.
Regardless, following point 2, mandate that all Git pull requests are made
against the new 5.x master; the 4.x legacy branch would have no commits
except minimal back-porting.
New pull requests are by default created against "master" branch. So if
5.x development would happen in "master" and 4.x in e.g. "legacy-4.0"
then no changes is needed.
But on github it is not possible to disallow users to create new pull
requests for non-default branch. When creating pull request there is a
button which open dialog to change target branch.
