[phpMyAdmin Developers] Relating phpMyAdmin release versions with library versions

[Isaac Bennetch]

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.