On Thu, 14 Feb 2019 at 13:34, Arvids Godjuks <arvids.godj...@gmail.com> wrote:
> I agree with this sentiment and the general idea of shipping JIT as > experimental in 7.4 and required to build with a configure flag. > master for 8.0 is going to contain much more and be more unstable and not > practical for testing what JIT can do at that point due to all other > features and improvements going into it like additional optimizations and > platform support. > This is a reasonable point - other things will be happening on master which make JIT harder to test. I guess part of the decision here depends what those are. If the idea is for someone to build a tagged release (7.4.x) with an experimental configure flag, could we have a half-way house, by tagging official "JIT preview builds"? These would mostly just be commits of master where things happened to be reasonably stable, with the occasional throwaway branch reverting out something broken. We could then publicise these builds as "try PHP 8 today" in all the same places we would have publicised "try --enable-jit today". If anything, it could be more visible, because every few months we could post a new tag to the home page of php.net. To compare strategies: * Experimental feature in 7.4, port all JIT changes. Users get a current snapshot of JIT every release of 7.4.x; maintainers have to port a lot of code that may never be used. * Experimental feature in 7.4, mostly frozen when 7.4.0 ships. Users get an out of date JIT to play with; maintainers have to make sure it's not completely broken during 7.4 cycle. * "JIT preview" tags every few months, with no published schedule. Users get a current snapshot of JIT every few months; maintainers only manage the implementation in one branch, and choose when to tag a new preview. Regards, -- Rowan Collins [IMSoP]
