Re: Changing to a more recent-ish PHP_VERSION_DEFAULT ?

[Greg Troxel <gdt%lexort.com@localhost>]

Jean-Yves Migeon <jym%helkyn.org@localhost> writes:

> Le 12/11/2023 à 19:36, Benny Siegert a écrit :
>> I am not sure what the official process is, or if there even is one. What I do for Go is:
>> 1. Change the default version in my working copy.
>> 2. Do a bulk build with all dependent packages.
>> 3. Fix the breakage (usually by updating the package), or notify the maintainer if I cannot fix it.
>> 4. Commit the change of default version.
>
> LGTM, I will give it a "go" with 8.1 then

We don't really have an official process.  What we have is

  - a general idea that when someone commits a change, they believe it
    will not cause regressions on any platform, including platforms they
    have not tested on, or if it does, that those regressions can be
    found and fixed before the next freeze starts.  This implies that
    the closer we are the more careful you have to be.

  - changing the default version of a language requires PMC approval
    on/after 12/1, as has been written down in
    https://www.pkgsrc.org/quarterly/ for a really long time now.


More recently, there have been meta-pkgs/bulk-test-foo packages, for
boost, rust, go, llvm, intended to be used for "locally update
something, and then build that meta-package".  That is hugely better
than nothing in that it tests building, but 1) it doesn't test that
things work correctly and 2) it doesn't test that they are ok on some
other platform.  But, I'd say that we are converging on something like
this being appropriate.

So sure, flip your tree, and build everything that uses php that you
think anybody cares about.  As I have said before, if we are going to
change before the branch, sooner is better than later.

It would be great to commit a meta-pkgs/bulk-test-php, but that's less
important than actuallly building things.