Developers March 2022

developers@phpmyadmin.net

3 participants
3 discussions

phpMyAdmin 4.9.10 and 5.1.3 are released
by Isaac Bennetch 24 Apr '22

24 Apr '22

The phpMyAdmin team announces the release of versions 4.9.10 and 5.1.3. These versions primarily address a regression that caused the navigation pane to not function correctly when multiple pages of tables were shown. Version 5.1.3 includes a security hardening improvement. The issue, reported by Rafael Pedrero, could allow users to cause an error that would reveal the path on disk where phpMyAdmin is running from. We believe this requires the server to be running with display_errors on, which is not the recommended setting for a production environment. Version 5.1.3 includes a few other minor bug fixes and is recommended for all users. Note that version 4.9 is in extended security support only. Version 5.2.0 is in final testing and is expected to replace the 5.1 branch in the coming week or weeks, with no changes to required versions of PHP or database server. For the phpMyAdmin team, Isaac

2 1

MYSQL DATABASE DROPPED ACCIDENTALLY
by Sir Appolly. 15 Mar '22

15 Mar '22

Hello team,how can i get my database accidentally droped. I am using xammp and currently there is no backup. Sure Regards, Sir Appolly, appolo2.bohr(a)yahoo.com / hi.appoli(a)gmail.com +254711-194-068 / +254759-868-172

2 2

About branch maintenance
by Isaac Bennetch 06 Mar '22

06 Mar '22

Hi, It has occurred to me that our current branches have diverged significantly from QA_4_9 and that our current system of merging any change from QA_4_9 to QA_5_1 then to master doesn't seem ideal to me any longer. This makes security merges difficult. This got messy at the point where we decided to continue supporting 4.9 for urgent fixes and security fixes, because prior to 4.9, security fixes would generally be assigned a fourth version number (such as 2.11.2.2 or 4.1.14.8). That fourth version number does not conform very well with semver and we've adapted to releasing a new "patch" release for security fixes (4.9.7, for instance). Under the older system, a branch MAINT_4_1_14 would be created for the security fixes for 4.1.14.x, because a QA_ branch would get merged ahead to newer branches but the MAINT branch was not meant to be merged. Similar changes could be git cherry-picked to future branches instead. Here's what I'm proposing: * Make a break from merging QA_4_9, remove the QA_4_9 branch and replace it with MAINT_4_9 (not MAINT_4_9_8, which would be the old way). We're really getting towards the end of wanting to support 4.9 anyway, but this will allow us to maintain 4.9 without complicated merges to the 5.x branches. It's easy to see how we got in this situation because at first we were still sort of supporting 4.9 for bug fixes and slowly switched to security only, but this is a good time to commit to doing this the right way. As a reminder, since we're releasing 5.2.0-rc1, QA_5_2 is going to be created from master, and QA_5_2 will be frozen for new features; it will become bug fix only. Once 5.2.0 is officially released, QA_5_1 will be removed. I don't believe this will cause any problems with compatibility with very old PHP versions as there should be significant overlap. Regards, Isaac

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Developers March 2022