Pali,
Great! Now we can start moving forward.
Sorry if my responses have been intermittent - first week at new job.
Regards,
Patrick
On 9/16/17 4:35 AM, p...@cpan.org wrote:
On Friday 15 September 2017 04:06:57 Patrick M. Galbraith wrote:
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.
I prepared branch master-new, which is based on current DBD-mysql master
branch and revert state to pre-4.043 version, including all changes done
after 4.043 release to master branch. I have this master-new branch in
my fork. If you want you can use it...
https://github.com/pali/DBD-mysql/tree/master-new
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.
