Procedure to deprecate old versions of software by adamjstewart · Pull Request #20767 · spack/spack

adamjstewart · 2021-01-09T23:14:36Z

See proposal in #15896

Implement version-level deprecated arg
Implement package-level deprecated arg
Documentation
Testing?

Example usage:

$ spack fetch [email protected]
==> Warning: [email protected] is deprecated and may be removed in a future Spack release.
==>   Fetch anyway? [y/N] n
==> Error: Will not fetch [email protected]
If you are willing to be a maintainer for this version of the package, submit a PR to remove `deprecated=False`, or use `--deprecated` to skip this check.

I'm not sure how to implement the package-level arg, but we can always apply the arg to all versions of a package.

adamjstewart · 2021-01-09T23:15:43Z

lib/spack/spack/package.py

            tty.debug('No fetch required for {0}: package has no code.'
                      .format(self.name))

-        start_time = time.time()


Previously, "fetch time" would include the time that Spack waited at the prompt for the user to confirm or deny no-checksum/deprecated versions.

sethrj

Looks good to me! I think that once we consider removing particular versionss, though, we'll need to have a placeholder for range of removed versions that gives an error when one is selected during concretization (e.g. deleted_versions(':2.56.4')). Otherwise, we will likely see more bizarre concretization errors like this one.

adamjstewart · 2021-02-01T17:32:55Z

Ping @spack/merge-to-develop

cosmicexplorer

I'm not sure how to implement the package-level arg, but we can always apply the arg to all versions of a package.

I think this sounds like a good idea!

etc/spack/defaults/config.yaml

lib/spack/docs/packaging_guide.rst

lib/spack/spack/cmd/fetch.py

lib/spack/spack/cmd/patch.py

sethrj · 2021-02-09T18:51:08Z

Yay deprecations! Next, removals.

becker33 · 2021-02-09T19:01:59Z

@adamjstewart is there interaction between this PR and the spack deprecate command that we should consider?

adamjstewart · 2021-02-09T19:04:21Z

I could see that being useful. I've never used that command. It's for deprecating versions with security vulnerabilities, right? Or is it for deprecating modules? One possible option would be to add a flag to search for installed software that is deprecated.

becker33 · 2021-02-10T18:27:01Z

It's for deprecating versions with security vulnerabilities (or with correctness bugs). It basically just symlinks one spec into the location of another.

carns · 2021-02-15T15:41:10Z

FYI, I tried out the deprecated tag for a package.py just now. It works great, but I noticed that it resolved/installed all dependencies before displaying the prompt informing the user that the package/version is deprecated. Not a big deal, but it might be nicer to present this prompt immediately before taking further action.

adamjstewart · 2021-02-15T16:54:28Z

I agree. I'm not sure how to do this though. Probably similar to how conflicts works, but with an option to ignore it.

alalazo · 2021-02-18T08:37:41Z

@becker33 @adamjstewart @scheibelp @tldahlgren @tgamblin Did anybody think how to handle these version deprecations during a release cycle? Would it make sense to use a v0.17:

version('1.2.3', sha256='...', deprecated='v0.17')

or a similar value instead of a Boolean? The issue I see is that if we use just True or False it would be a nightmare to check what to remove for any given major release of Spack, since for every deprecated line we'll have to go to the git log and check when it was added in develop. If instead we use vMAJOR.MINOR we can just grep for the previous version number when we'll cut a release and the procedure would be much faster.

adamjstewart · 2021-02-18T13:45:07Z

That's not a bad idea. But we can also grep for deprecated=True right after a new release and remove anything for the next release.

alalazo · 2021-02-18T14:12:40Z

I think that means we should ensure that no deprecated=True goes into develop during the days when we cut a release. Anyhow, I just want to make sure we have a clear strategy for that. Would it take a lot of changes to go with strings as proposed above?

adamjstewart · 2021-02-18T15:58:04Z

It wouldn't take very many changes to do this. I think it's still fine for deprecated=True to slip into develop, as we only promise that versions won't be removed without deprecation in a release, it's fine in develop. For example:

Day 1: deprecate version
Day 2: new release of Spack
Day 3: remove version

I don't see a problem with the above scenario. For anyone moving from release to release they will have a full release cycle to warn them.

alalazo · 2021-02-18T16:09:54Z

    Day 2: new release of Spack
---> deprecated=True slips in develop after release
    Day 3: remove version

adamjstewart · 2021-02-18T17:45:51Z

Ah, yes, that's not allowed. Aside from code review, I guess the easiest way to enforce that with unit tests would be your version suggestion.

adamjstewart added feature A feature is missing in Spack fetching labels Jan 9, 2021

adamjstewart commented Jan 9, 2021

View reviewed changes

adamjstewart requested review from alalazo, ax3l, cosmicexplorer and sethrj January 9, 2021 23:17

sethrj previously approved these changes Jan 10, 2021

View reviewed changes

This was referenced Jan 10, 2021

Update NEURON simulator package : new versions and cmake build system #20582

Merged

llvm-doe: add new package #20719

Merged

shintaro-iwasaki mentioned this pull request Jan 15, 2021

sollve: remove sollve package #20944

Closed

This was referenced Jan 16, 2021

lampss: add warning about fetching patch vs. stable versions #5390

Closed

Installation issue: Ambert Tools 20 #19544

Closed

[acts] Add version 4.1, bump minimal dependencies #21128

Merged

replace margo pkg with updated mochi-margo pkg #20273

Merged

adamjstewart marked this pull request as ready for review January 24, 2021 18:17

adamjstewart mentioned this pull request Jan 25, 2021

Installation issue: mxnet #21260

Closed

4 tasks

adamjstewart force-pushed the features/deprecated branch from c6783cd to 6dc1116 Compare January 25, 2021 20:11

This was referenced Jan 27, 2021

FEniCS: update of packages to support 2019.1.0 #21207

Merged

mxnet: convert to CMakePackage #21385

Merged

cosmicexplorer previously approved these changes Feb 1, 2021

View reviewed changes

etc/spack/defaults/config.yaml Show resolved Hide resolved

lib/spack/docs/packaging_guide.rst Outdated Show resolved Hide resolved

lib/spack/spack/cmd/fetch.py Show resolved Hide resolved

lib/spack/spack/cmd/patch.py Show resolved Hide resolved

adamjstewart dismissed stale reviews from cosmicexplorer and sethrj via 6484053 February 2, 2021 17:45

adamjstewart force-pushed the features/deprecated branch from 6dc1116 to 6484053 Compare February 2, 2021 17:45

adamjstewart added 5 commits February 7, 2021 10:56

Procedure to deprecate old versions of software

e45737a

Add documentation

43ced13

Fix bug in logic

91bbb2f

Update tab completion

9b2d767

Deprecate legacy packages

2e018ae

adamjstewart added 2 commits February 7, 2021 10:58

Deprecate old mxnet as well

8b86c44

More explicit docs

5e046b6

adamjstewart force-pushed the features/deprecated branch from 6484053 to 5e046b6 Compare February 7, 2021 16:58

sethrj approved these changes Feb 9, 2021

View reviewed changes

sethrj merged commit 7ccb999 into spack:develop Feb 9, 2021

adamjstewart deleted the features/deprecated branch February 9, 2021 18:58

ChristianTackeGSI mentioned this pull request Feb 11, 2021

mesa18: Do not deprecate for now #21627

Merged

alalazo mentioned this pull request May 10, 2021

ASP-based solver: account for deprecated versions #23491

Merged

Conversation

adamjstewart commented Jan 9, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adamjstewart Jan 9, 2021

Choose a reason for hiding this comment

Uh oh!

sethrj left a comment

Choose a reason for hiding this comment

Uh oh!

adamjstewart commented Feb 1, 2021

Uh oh!

cosmicexplorer left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sethrj commented Feb 9, 2021

Uh oh!

becker33 commented Feb 9, 2021

Uh oh!

adamjstewart commented Feb 9, 2021

Uh oh!

becker33 commented Feb 10, 2021

Uh oh!

carns commented Feb 15, 2021

Uh oh!

adamjstewart commented Feb 15, 2021

Uh oh!

alalazo commented Feb 18, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adamjstewart commented Feb 18, 2021

Uh oh!

alalazo commented Feb 18, 2021

Uh oh!

adamjstewart commented Feb 18, 2021

Uh oh!

alalazo commented Feb 18, 2021

Uh oh!

adamjstewart commented Feb 18, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

adamjstewart commented Jan 9, 2021 •

edited

Loading

alalazo commented Feb 18, 2021 •

edited

Loading