Celeritas: new version 0.5.1

[sethrj]

This adds Celeritas 0.5.1, marks 0.5.0 as deprecated, and omits a removed (but harmless) cmake option from the command line for newer versions.

[wdconinc]

Could we avoid deprecating older versions right away? This leads to users upgrading spack (even the regular develop-$(date) weekly snapshots, or develop with a git pull) and finding out that their environments don't concretize anymore unless they upgrade. I'd prefer we give them a path to upgrade on their own terms and timeline, e.g. keep the two most recent versions not deprecated.

I don't think we should use deprecation to force users to upgrade more quickly than they chose, but instead use it to reduce our support burden (or prevent users from running with insecure software).

[drbenmorgan]

I'll defer to @sethrj on the deprecation question for Celeritas, I guess this is going to be on a package by package basis (I'm thinking with my Geant4 hat on here, and whether it's good for upstream projects to formally document a deprecation policy that can inform spack here).

[wdconinc]

I'll defer to @sethrj on the deprecation question for Celeritas, I guess this is going to be on a package by package basis (I'm thinking with my Geant4 hat on here, and whether it's good for upstream projects to formally document a deprecation policy that can inform spack here).

And I am fully willing to defer to the maintainers here, regardless what you decide, but I wanted to raise the point. For geant4 for example, since you brought it up, it has been very helpful to have input on whether newer datasets can be used with older geant4 versions etc. But I note that even so, geant4 has not deprecated any older versions since there is often interest in being able to replicate older simulations, even if it is understood that these older versions are not encouraged for new simulations.

[sethrj]

Certainly, and honestly I didn't realize how severe the "avoid deprecated" mandate was... I know there have been many conversations over the years, often led by @adamjstewart

[wdconinc]

I didn't realize how severe the "avoid deprecated" mandate was

The story could be different if we could "un-deprecate" selected packages. E.g. I am ok with deprecated celeritas versions, but not with deprecated openssh versions.

[adamjstewart]

My thoughts on deprecation are roughly documented here: https://spack.readthedocs.io/en/latest/packaging_guide.html#deprecating-old-versions

Basically, if you have a good reason like security vulnerability or packaging complexity, I'm pro-deprecation, but if you have no reason other than it lets me delete 1 line, then I'm anti-deprecation.

[sethrj]

Is "has bugs that won't be fixed until the next major revision" a good reason?

[wdconinc]

Is "has bugs that won't be fixed until the next major revision" a good reason?

By that reason, wouldn't we deprecate every single older version, for every package? Is there a package out there that has no bugs and only adds new features (without bugs) in each new release?

[wdconinc]

Checksum verified. @sethrj Please feel free to merge.

[adamjstewart]

Agreed, all versions of all software have bugs, we don't usually remove them. Reproducibility is important, and not all software works with the latest version of all other software.

[sethrj]

By that reason, wouldn't we deprecate every single older version, for every package? Is there a package out there that has no bugs and only adds new features (without bugs) in each new release?

It's not uncommon to keep a stable branch around that gets incremental patches; CMake for example introduces new features in minor, and maintains a few older minor versions with bugfix patches.

[sethrj]

Thanks @wdconinc @adamjstewart @drbenmorgan for the discussion and review!