haskell
Filter Setup flags: filter working dir on < 3.13
The --working-dir flag is only available for Cabal >= 3.13. This commit fixes an incorrect conditional: we only filtered out this flag for Cabal < 3.11, instead of < 3.13.
Fixes #9940
PR template is missing @sheaf , is this a user-visible (cabal/API) change or not?
@andreasabel At the moment the testing infrastructure does not yet allow a recent cabal install version to be tested against multiple Cabal versions (although @mpickering has recently laid out the foundations for this). So, just like for the remaining filtered flags, there's no easy way to add a test for this one.
@ffaf1 This is a change to how cabal-install invokes Cabal. There should be no visible change. This is fixing a bug (#9940) where cabal-install was passing too-recent flags to an older Cabal version.
@ffaf1 This is a change to how cabal-install invokes Cabal. There should be no visible change. This is fixing a bug (https://github.com/haskell/cabal/issues/9940) where cabal-install was passing too-recent flags to an older Cabal version.
I appreciate the explanation.
The more we use the two PR templates, the easier it is not to have hot messes during release time like #9952.
The more we use the two PR templates, the easier it is not to have hot messes during release time like #9952.
The PR templates would have achieved nothing for #9952 in particular, even if they are useful in other situations.
#9952 was caused by a change which would have filled any of the templates trivially. It happened to break GHC 8.2 which wasn't tested in CI. Rather, when CI was dropped for GHC 8.2 the bounds (of the base dependency) for Cabal at the time should have been updated to disallow the versions we stopped testing. Right?
PR template is missing @sheaf , is this a user-visible (cabal/API) change or not?
This fixes a bug in the master version of the cabal-install executable. As reported in #9940, this bug currently only impacts people who build cabal-install from master and try to use it to compile a package with a custom setup with Cabal == 3.12.*. If this makes it into the next cabal-install release then no released cabal-install version will be affected by this bug.
Rather, when CI was dropped for GHC 8.2 the bounds (of the base dependency) for Cabal at the time should have been updated to disallow the versions we stopped testing. Right?
Yes, but one part of https://github.com/haskell/cabal/issues/9952 is that dropping GHC 8.2 has not been recorded in release notes. With proper PR template and the new clearer definition of a user-visible change, the PR that tweaked CI would have to include a changelog file so the release notes would be fine. With some luck, and the recent extra comments in CI scripts, following the process carefully would also make omitting the base bound harder.
Also, why are we arguing about the process here? If you don't have the time to follow the process, apologize and move on. If you don't like the process, file a ticket with proposed changes. I don't think arguing with a person that points out the process has not been followed is productive.
I've added a test (PackageTests/WorkingDir) and confirmed that it fails before the patch and succeeds after.