As a packager I want the possibility to attach variants to a spec depending on its version so that I can model in a more natural way the evolution of the features of a package over time.

Rationale

Many packages evolve during time and they add or remove features as they see fit. As we support more and more versions of the same package we might be faced with the problem of having either to expose just the "lowest common denominator" (i.e. only the features supported by all the versions) or to explicitly manage conflicts among variants and package versions. A prime example of this is boost, for which we have an issue open since a couple of years (see #1486). If variants could depend on the package version this issue would be solved neatly.

Description

The proposal here is to extend the allowed syntax for the variant directive to allow for a version range to be specified:

class Boost(Package):
    ...
    variant('atomic', description='...', applies_to='@1.53:')

The directive above means that the variant atomic exists for the package starting at version 1.53. Any command that refers to it for a version that does not satisfy the constraint should fail with an error:

$ spack spec [email protected]+atomic
Input spec
--------------------------------
[email protected]+atomic

Concretized
--------------------------------
==> Error: Package boost has no variant 'atomic' at version 1.52.0 [the variant starts at 1.53.0]

This should also affect the concretizer in the other way around (if we ask for boost+atomic we have an implicit constraint on [email protected]:). Probably also spack info should be updated to match the new feature:

$ spack info boost
...
Variants:
    Name [Default]       Allowed values      Description                    Range of validity


    atomic [on]          True, False         Compile with atomic library    @1.53.0:
    chrono [on]          True, False         Compile with chrono library
...