Hi, I have a question about library version numbers when we perform a release of phpMyAdmin.
For example, in composer.json we currently require sql-parser 3.3 or newer, which is good, because then any newer fixes get incorporated on release without needing to constantly chase the version in composer.json.
However, if someone is testing with release 4.6.0-rc2 and we fix something in sql-parser, a developer checking out the git tag RELEASE_4_6_0RC2 will get the updated sql-parser. It seems the only way to test with the sql-parser version included in a release is to actually download the released tarball, whereas in the past we were able to simply checkout the corresponding git tag. It feels like a workaround instead of a solution, but I'm not sure that we can realistically do anything to improve it.
Furthermore, the demo servers will always be running the most up-to-date sql-parser release, even when the corresponding release has an older version (at least, updated as often as pma-demo-update is called), so asking a user to test against the demo server takes on a slightly different meaning when debugging.
Does this sound right, and is it really anything to worry about in the scheme of things? Or am I getting concerned about a minor thing?
Thanks Isaac
Hi
Dne 2.3.2016 v 15:17 Isaac Bennetch napsal(a):
Hi, I have a question about library version numbers when we perform a release of phpMyAdmin.
For example, in composer.json we currently require sql-parser 3.3 or newer, which is good, because then any newer fixes get incorporated on release without needing to constantly chase the version in composer.json.
However, if someone is testing with release 4.6.0-rc2 and we fix something in sql-parser, a developer checking out the git tag RELEASE_4_6_0RC2 will get the updated sql-parser.
Not really, we're still using embedded copies in 4.6, this has been changed to composer for master only so far.
It seems the only way to test with the sql-parser version included in a release is to actually download the released tarball, whereas in the past we were able to simply checkout the corresponding git tag. It feels like a workaround instead of a solution, but I'm not sure that we can realistically do anything to improve it.
Furthermore, the demo servers will always be running the most up-to-date sql-parser release, even when the corresponding release has an older version (at least, updated as often as pma-demo-update is called), so asking a user to test against the demo server takes on a slightly different meaning when debugging.
Does this sound right, and is it really anything to worry about in the scheme of things? Or am I getting concerned about a minor thing?
The released version will contain composer.lock file with information about which versions were shipped in the release, so that can be easily tracker. However using git tag it will indeed get by default most up to date version.
On 3/2/16 9:22 AM, Michal Čihař wrote:
Hi
Dne 2.3.2016 v 15:17 Isaac Bennetch napsal(a):
Hi, I have a question about library version numbers when we perform a release of phpMyAdmin.
For example, in composer.json we currently require sql-parser 3.3 or newer, which is good, because then any newer fixes get incorporated on release without needing to constantly chase the version in composer.json.
However, if someone is testing with release 4.6.0-rc2 and we fix something in sql-parser, a developer checking out the git tag RELEASE_4_6_0RC2 will get the updated sql-parser.
Not really, we're still using embedded copies in 4.6, this has been changed to composer for master only so far.
This is true, as you corrected me in our other message, so of course my report should have written about 4.7.0-rc1 instead of 4.6.
It seems the only way to test with the sql-parser version included in a release is to actually download the released tarball, whereas in the past we were able to simply checkout the corresponding git tag. It feels like a workaround instead of a solution, but I'm not sure that we can realistically do anything to improve it.
Furthermore, the demo servers will always be running the most up-to-date sql-parser release, even when the corresponding release has an older version (at least, updated as often as pma-demo-update is called), so asking a user to test against the demo server takes on a slightly different meaning when debugging.
Does this sound right, and is it really anything to worry about in the scheme of things? Or am I getting concerned about a minor thing?
The released version will contain composer.lock file with information about which versions were shipped in the release, so that can be easily tracker. However using git tag it will indeed get by default most up to date version.
I think composer.lock will help with this, plus sql-parser isn't something that should see heavy development changes, only bug fixes which will probably be obvious across all released branches. I guess this isn't as big of a problem as I first thought.
-
Isaac Bennetch -
Michal Čihař