RE: [PHP-DEV] re2c version(s)
| From: | Anatol Belski | Date: | Fri, 13 Jul 2018 19:08:18 +0000 |
| Subject: | RE: [PHP-DEV] re2c version(s) | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-102807@lists.php.net to get a copy of this message | ||
Hi,
> -----Original Message-----
> From: php@golemon.com <php@golemon.com> On Behalf Of Sara Golemon
> Sent: Friday, July 13, 2018 8:22 PM
> To: Dmitry Stogov <dmitry@zend.com>
> Cc: Nikita Popov <nikita.ppv@gmail.com>; PHP internals list
> <internals@lists.php.net>; Stanislav Malyshev <smalyshev@gmail.com>;
> derick@derickrethans.nl; Christoph M. Becker <cmbecker69@gmx.de>
> Subject: Re: [PHP-DEV] re2c version(s)
>
> On Fri, Jul 13, 2018 at 7:00 AM, Dmitry Stogov <dmitry@zend.com> wrote:
> > OK. Dropping files and requirement for re2c 1.0.0. Right?
> >
> +1 to removing them from git (except timelib as Derick noted).
>
> The minimum requirement is reasonable in terms of reproducibility, but should
> that be specific to master/7.3?
>
The tool version is in most cases irrelevant for the generated files. I recall there was some issues
with re2c 0.16 and ext/date in 7.1, but that's the only case I could recall. But limiting the
tool version seems hard for another reason - LTS distros won't upgrade them. Fe. Jessie still
has re2c 0.13.5, bison 3.0.2 by default. We'd effectively force anyone to either upgrade their
distros, or to use some workarounds like manually installing the required tools into a prefix and
prepending it to the path.
> I ask, because my release builder for 7.2 (and 7.1 if Joe is using
> Davey's builder) is using re2c 0.13.5 . I don't imagine the risk of
> updating re2c mid-relase is particularly high, but it is non-zero.
>
Normally RMs would define the tool versions that are expected to be stable and that are always used
for the official tarballs. In the case of 7.0, it'd be always re2c 0.13.5 and bison 3.0.2,
where ever I'd produce the tarball (even I don't always use Jessie for packaging). We
probably should take this into the release process docs, if it isn't there already.
Following up on Dmitry's idea - what if we'd not remove the generated files, but instead
would define some minimal tool versions that have to be used by default for the core? That however
also needs to stand in unison with how the official tarballs are produced. Also, it might be
possible, that some particular code needs some particular tool version, which should be stated
explicitly.
Regards
Anatol