Description
| Q | A |
|---|---|
| Bug report? | Yes |
| Feature request? | No |
| BC Break report? | Yes |
| RFC? | Yes |
| Symfony version | 3.4.0 |
In #23708, a Windows-only backwards compatibility break was introduced in Symfony/Process. The claim was that Windows processes were already failing w/out a cwd. It is unclear to me what the basis of this assertion was, but it seems that it might have been in error.
With Symfony 3.4, Windows users are now reporting b/c breaks in consolidation/robo#652. I don't have a lot of Windows background myself, but Robo has Windows tests on Appveyor that pass with Symfony/Process 3.3, and fail with Symfony/Process 3.4. The relevant PR is consolidation/robo#658
Failing appveyor test: https://ci.appveyor.com/project/greg-1-anderson/robo/build/1.0.382
Working appveyor test: https://ci.appveyor.com/project/greg-1-anderson/robo/build/1.0.380
n.b. The only difference between the working and non-working tests are the dependencies in the composer.lock file. The passing test on the master branch is locked to Symfony/Process 3.3.
If Symfony does wish to break b/c for Windows users for some reason, then Robo could still maintain b/c in its 1.x branch and conform with Symfony's new expectations in a future 2.x branch. However, the scope of this issue will impact Windows Symfony/Process users beyond the domain of Robo, so it might be worth considering make the Windows code path in Symfony/Process 3.4 continue to pass through, just as the non-Windows code path does.