Hi,
On Fri, Nov 25, 2016 at 6:32 PM, Isaac Bennetch bennetch@gmail.com wrote:
Do we need a quick release of 4.6.51 because of #12735 ?
I think we can indeed do a quick release to include the fix for #12735. We would not want another one like #12480 to be present and remain unfixed until the next two months (assuming the new two-month release cycle).
Regards, Deven Bansod
Isaac Bennetch píše v Pá 25. 11. 2016 v 07:02 -0600:
Do we need a quick release of 4.6.51 because of #12735 ?
Sounds like a good idea.
I'll work on the release in a bit. I'm unable to reproduce this on my machine (quickly tested with 'mysql' and 'mysqli' extensions on RELEASE_4_6_5); is there a particular factor I should mention in the notes that can cause or avoid this issue?
On Fri, Nov 25, 2016 at 8:02 AM, Isaac Bennetch bennetch@gmail.com wrote:
Do we need a quick release of 4.6.51 because of #12735 ?
Hi Isaac,
On Fri, Nov 25, 2016 at 9:41 PM, Isaac Bennetch bennetch@gmail.com wrote:
I'll work on the release in a bit. I'm unable to reproduce this on my machine (quickly tested with 'mysql' and 'mysqli' extensions on RELEASE_4_6_5); is there a particular factor I should mention in the notes that can cause or avoid this issue?
The errors can be reproduced when config options 'only_db' and/or 'hide_db' are set in the config.inc.php file. Hope it helps.
Regards, Deven Bansod
On Fri, Nov 25, 2016 at 12:04 PM, Deven Bansod devenbansod.bits@gmail.com wrote:
Hi Isaac,
On Fri, Nov 25, 2016 at 9:41 PM, Isaac Bennetch bennetch@gmail.com wrote:
I'll work on the release in a bit. I'm unable to reproduce this on my machine (quickly tested with 'mysql' and 'mysqli' extensions on RELEASE_4_6_5); is there a particular factor I should mention in the notes that can cause or avoid this issue?
The errors can be reproduced when config options 'only_db' and/or 'hide_db' are set in the config.inc.php file. Hope it helps.
Thanks, that does clear it up completely.
Regards, Deven Bansod
Developers mailing list Developers@phpmyadmin.net https://lists.phpmyadmin.net/mailman/listinfo/developers
On Fri, Nov 25, 2016 at 8:02 AM, Isaac Bennetch bennetch@gmail.com wrote:
Do we need a quick release of 4.6.51 because of #12735 ?
What's the best way to handle this? Since QA_4_6 is so fresh, should I just base the release on QA_4_6 (which at the moment includes Michal's Node.js fix and a few language improvements? I think that's better than cherry-picking the fix back to a branch created from RELEASE_4_6_5 because the history will be cleaner, but it will include a few more fixes than just the issue mentioned.
Hi
Isaac Bennetch píše v Pá 25. 11. 2016 v 12:21 -0500:
On Fri, Nov 25, 2016 at 8:02 AM, Isaac Bennetch bennetch@gmail.com wrote:
Do we need a quick release of 4.6.51 because of #12735 ?
What's the best way to handle this? Since QA_4_6 is so fresh, should I just base the release on QA_4_6 (which at the moment includes Michal's Node.js fix and a few language improvements? I think that's better than cherry-picking the fix back to a branch created from RELEASE_4_6_5 because the history will be cleaner, but it will include a few more fixes than just the issue mentioned.
There is nothing Node.js related from me, just sanity checks in php- gettext to avoid miserable failure when mbstring is not there. This should be fine for release. So I'd release from QA_4_6.
On Fri, Nov 25, 2016 at 1:10 PM, Michal Čihař michal@cihar.com wrote:
Hi
Isaac Bennetch píše v Pá 25. 11. 2016 v 12:21 -0500:
On Fri, Nov 25, 2016 at 8:02 AM, Isaac Bennetch bennetch@gmail.com wrote:
Do we need a quick release of 4.6.51 because of #12735 ?
What's the best way to handle this? Since QA_4_6 is so fresh, should I just base the release on QA_4_6 (which at the moment includes Michal's Node.js fix and a few language improvements? I think that's better than cherry-picking the fix back to a branch created from RELEASE_4_6_5 because the history will be cleaner, but it will include a few more fixes than just the issue mentioned.
There is nothing Node.js related from me, just sanity checks in php- gettext to avoid miserable failure when mbstring is not there. This should be fine for release. So I'd release from QA_4_6.
I was slightly mistaken, the commit I was referring is Node.php, not Node.js — anyway, I'll release from QA_4_6 this evening.
issue #12735 Incorrect parameters to escapeString in Node.php
See also https://github.com/phpmyadmin/phpmyadmin/compare/RELEASE_4_6_5...QA_4_6
Regards
-- Michal Čihař | https://cihar.com/ | https://weblate.org/
Developers mailing list Developers@phpmyadmin.net https://lists.phpmyadmin.net/mailman/listinfo/developers
Hi,
On Sat, Nov 26, 2016 at 2:58 AM, Isaac Bennetch bennetch@gmail.com wrote:
I was slightly mistaken, the commit I was referring is Node.php, not Node.js — anyway, I'll release from QA_4_6 this evening.
issue #12735 Incorrect parameters to escapeString in Node.php
See also https://github.com/phpmyadmin/phpmyadmin/compare/RELEASE_4_6_5...QA_4_6
Do we include the fix for #12736 (I am pushing it in a few minutes, just wanted to ask once since you are going to make the release from QA_4_6) too ? It actually makes creation of a new table very difficult, which I believe would be a very important task for users.
Regards, Deven Bansod
On Fri, Nov 25, 2016 at 10:42 PM, Deven Bansod devenbansod.bits@gmail.com wrote:
Hi,
On Sat, Nov 26, 2016 at 2:58 AM, Isaac Bennetch bennetch@gmail.com wrote:
I was slightly mistaken, the commit I was referring is Node.php, not Node.js — anyway, I'll release from QA_4_6 this evening.
issue #12735 Incorrect parameters to escapeString in Node.php
See also https://github.com/phpmyadmin/phpmyadmin/compare/RELEASE_4_6_5...QA_4_6
Do we include the fix for #12736 (I am pushing it in a few minutes, just wanted to ask once since you are going to make the release from QA_4_6) too ? It actually makes creation of a new table very difficult, which I believe would be a very important task for users.
Yes, this fix should go in 4.6.5.1 as well. It is annoying. I was just in the process of uploading (without it), so I'm glad you wrote. I'll delay the release until #12736 is fixed.
Thank you.
Regards, Deven Bansod
Developers mailing list Developers@phpmyadmin.net https://lists.phpmyadmin.net/mailman/listinfo/developers
Hi,
On Sat, Nov 26, 2016 at 9:43 AM, Isaac Bennetch bennetch@gmail.com wrote:
Yes, this fix should go in 4.6.5.1 as well. It is annoying. I was just in the process of uploading (without it), so I'm glad you wrote. I'll delay the release until #12736 is fixed.
I have just pushed the fix for #12736 just now, I guess we can wait for the test suite to complete. (Though I have tested it, but it would be great if you could just try it out once).
Regards, Deven Bansod
Hi
Isaac Bennetch píše v Pá 25. 11. 2016 v 07:02 -0600:
Do we need a quick release of 4.6.51 because of #12735 ?
I wonder whether we should not release 4.6.5.2 because of #12765:
https://github.com/phpmyadmin/phpmyadmin/issues/12765
Leaving this unfixed for two months sounds annoying. Alternative would be to release 4.6.6 way sooner than on the two month schedule.
On Dec 1, 2016, at 5:12 AM, Michal Čihař michal@cihar.com wrote:
Hi
Isaac Bennetch píše v Pá 25. 11. 2016 v 07:02 -0600:
Do we need a quick release of 4.6.51 because of #12735 ?
I wonder whether we should not release 4.6.5.2 because of #12765:
https://github.com/phpmyadmin/phpmyadmin/issues/12765
Leaving this unfixed for two months sounds annoying. Alternative would be to release 4.6.6 way sooner than on the two month schedule.
I don't have a strong feeling about this. I dislike making too many releases too often (and we could easily end up pushing point releases for every moderate bug), but this is indeed rather inconvenient. I'm leaning slightly towards doing 4.6.5.2, but would also not be against a quicker release of 4.6.6.
I keep thinking that anything affecting data import and export (or login, for that matter) should get fixed as soon as possible, which does mean 4.6.5.2, so that's why I'm leaning in that direction.
-- Michal Čihař | https://cihar.com/ | https://weblate.org/ _______________________________________________ Developers mailing list Developers@phpmyadmin.net https://lists.phpmyadmin.net/mailman/listinfo/developers
Hi
Isaac Bennetch píše v Čt 01. 12. 2016 v 06:27 -0500:
On Dec 1, 2016, at 5:12 AM, Michal Čihař michal@cihar.com wrote:
Hi
Isaac Bennetch píše v Pá 25. 11. 2016 v 07:02 -0600:
Do we need a quick release of 4.6.51 because of #12735 ?
I wonder whether we should not release 4.6.5.2 because of #12765:
https://github.com/phpmyadmin/phpmyadmin/issues/12765
Leaving this unfixed for two months sounds annoying. Alternative would be to release 4.6.6 way sooner than on the two month schedule.
I don't have a strong feeling about this. I dislike making too many releases too often (and we could easily end up pushing point releases for every moderate bug), but this is indeed rather inconvenient. I'm leaning slightly towards doing 4.6.5.2, but would also not be against a quicker release of 4.6.6.
I think this is especially problematic as it corrupts exported data and user might not notice this breakage until he needs the backup he made using broken code...
I keep thinking that anything affecting data import and export (or login, for that matter) should get fixed as soon as possible, which does mean 4.6.5.2, so that's why I'm leaning in that direction.
I'm fine with either choices :-).
On Sat, Dec 3, 2016 at 7:42 AM, Michal Čihař michal@cihar.com wrote:
Hi
Isaac Bennetch píše v Čt 01. 12. 2016 v 06:27 -0500:
On Dec 1, 2016, at 5:12 AM, Michal Čihař michal@cihar.com wrote:
Hi
Isaac Bennetch píše v Pá 25. 11. 2016 v 07:02 -0600:
Do we need a quick release of 4.6.51 because of #12735 ?
I wonder whether we should not release 4.6.5.2 because of #12765:
https://github.com/phpmyadmin/phpmyadmin/issues/12765
Leaving this unfixed for two months sounds annoying. Alternative would be to release 4.6.6 way sooner than on the two month schedule.
I don't have a strong feeling about this. I dislike making too many releases too often (and we could easily end up pushing point releases for every moderate bug), but this is indeed rather inconvenient. I'm leaning slightly towards doing 4.6.5.2, but would also not be against a quicker release of 4.6.6.
I think this is especially problematic as it corrupts exported data and user might not notice this breakage until he needs the backup he made using broken code...
I keep thinking that anything affecting data import and export (or login, for that matter) should get fixed as soon as possible, which does mean 4.6.5.2, so that's why I'm leaning in that direction.
I'm fine with either choices :-).
Having had a few days to think about it, I think we should release 4.6.5.2 to address the export issue. I don't see anything else in the QA_4_6 changelog that needs to be included.
I believe the best way to handle this is for me to git cherry-pick e61b2135da52051bb158c37b9eed35d734bf441c in to the 4.6.5.1 branch, which will bring only that fix in. I don't believe this will cause any trouble when merging in the future (besides, we don't expect to merge from RELEASE_4_6_5_2 in to QA_4_6 anyway).
If no one objects I plan to perform the release as soon as I'm able, which may be later today or tomorrow.
-- Michal Čihař | https://cihar.com/ | https://weblate.org/
Developers mailing list Developers@phpmyadmin.net https://lists.phpmyadmin.net/mailman/listinfo/developers
Hi Isaac
Isaac Bennetch píše v Ne 04. 12. 2016 v 10:57 -0500:
Having had a few days to think about it, I think we should release 4.6.5.2 to address the export issue. I don't see anything else in the QA_4_6 changelog that needs to be included.
I believe the best way to handle this is for me to git cherry-pick e61b2135da52051bb158c37b9eed35d734bf441c in to the 4.6.5.1 branch, which will bring only that fix in. I don't believe this will cause any trouble when merging in the future (besides, we don't expect to merge from RELEASE_4_6_5_2 in to QA_4_6 anyway).
Yes, the merge will go without problem.
If no one objects I plan to perform the release as soon as I'm able, which may be later today or tomorrow.
Sounds okay to me.
-
Deven Bansod -
Isaac Bennetch -
Michal Čihař