Skip to content

The naming of allow-newer #6930

@mpilgrem

Description

@mpilgrem

By way of context:

  • Cabal-1.20.0.0 (2014-04-20) introduced the --allow-newer[=pkgs] option to ignore the upper bound on all dependencies or dependencies on specified packages in Cabal files.

  • Stack 0.1.8.0 (2015-11-20) added an allow-newer configuration option, to ignore the bounds in Cabal files. It took its name from the Cabal option, despite having a different function.

  • Cabal-2.0.0.2 (2017-07-24) introduced a scope syntax to --allow-newer.

  • Cabal-2.0.0.2 (2017-07-24) also introduced an --allow-older[=pkgs] option.

  • Stack 2.9.3 (2022-12-16) allowed the Cabal files in which bounds would be ignored to be specified (with allow-newer-deps, following the form of allow-newer).

  • Stack 3.1.1 (2024-07-28) allowed --[no-]allow-deps on the command line (following the form of allow-newer).

This has confused some users, who expect that:

  • Stack's allow-newer configuration option should function as Cabal's --allow-newer option; and
  • are not sure if allow-newer-deps is allow-newer-in-deps (like the scoping in Cabal's option) or allow-newer-over-deps (like Cabal's option) - it is the former.

Given the passage of over 10 years, the ship may have sailed, but perhaps more descriptive Stack configuration options would be:

  • ignore-bounds \ --ignore-bounds
  • ignore-bounds-in

In respect of the bounds in the Cabal files of package versions included in a snapshot, Stack always trusts the snapshot over the Cabal files.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions