When to do this isn't clear. As this is a phar utility meant to be run in production environments, we should realise that enterprise takes a long time to update. My own work still runs 5.6 in a lot of places.
http://php.net/supported-versions.php
5.6 active support ended 19 Jan 2017 but security patches are until 31 Dec 2018
Perhaps one solution would be after we ship native mssql support #10 and proper odbc driver support #9, we could tag that as the last version that works on php 5.6, and make all future versions only work on php 7.0+
There is also the issue that we make use of signal handling for ctrl-c, and without looking far into it, there are problems in php 7.0 specifically with it, fixed in 7.1. It works in php 5.6. So we would have to look at that too when decided what version to support.
When to do this isn't clear. As this is a phar utility meant to be run in production environments, we should realise that enterprise takes a long time to update. My own work still runs 5.6 in a lot of places.
http://php.net/supported-versions.php
5.6 active support ended 19 Jan 2017 but security patches are until 31 Dec 2018
Perhaps one solution would be after we ship native mssql support #10 and proper odbc driver support #9, we could tag that as the last version that works on php 5.6, and make all future versions only work on php 7.0+
There is also the issue that we make use of signal handling for ctrl-c, and without looking far into it, there are problems in php 7.0 specifically with it, fixed in 7.1. It works in php 5.6. So we would have to look at that too when decided what version to support.