You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 12, 2022. It is now read-only.
I've been thinking about how to deprecate packages a bit more smoothly. Let me throw out an idea:
I'm not sure what happens to Pkg if you flat out nuke a whole package in METADATA, but what thing you could do is set the maximum Julia version for all versions of the to-be-deprecated package to the current release.
E.g. Trie.jl is being merged into DataStructures. We can set the maximum julia version for Trie to julia 0.2, and then when julia 0.3 (or 0.4?) comes out we can safely delete it (presumably).
The text was updated successfully, but these errors were encountered:
I don't think packages should be removed from METADATA.jl totally until there's a version bump. For example, if someone wants to replicate some results using a specific (older) version of Julia, they'll still need/want access to packages which have been removed or renamed.
I've been thinking about how to deprecate packages a bit more smoothly. Let me throw out an idea:
I'm not sure what happens to Pkg if you flat out nuke a whole package in METADATA, but what thing you could do is set the maximum Julia version for all versions of the to-be-deprecated package to the current release.
E.g. Trie.jl is being merged into DataStructures. We can set the maximum julia version for Trie to julia 0.2, and then when julia 0.3 (or 0.4?) comes out we can safely delete it (presumably).
The text was updated successfully, but these errors were encountered: