Proposal: procedure to deprecate old versions of software #15896
Replies: 2 comments 1 reply
-
I like this idea. |
Beta Was this translation helpful? Give feedback.
-
I really like and strongly support this proposal! In addition, I offer two angles which may be helpful from a project I've spent a lot of time with, which is how to deprecate these things in pants. Here's how pants does it: https://www.pantsbuild.org/docs/deprecation-policy. I think it could be useful to at least compare against that for any formal deprecation procedure. e.g.:
The second part I'd like to mention is the python API, which is really nice and I think jives a lot with spack's style. See https://github.com/pantsbuild/pants/blob/9a8e1f3a97abb24275f8021491c215449ba4c649/src/python/pants/base/deprecated_test.py#L65-L68, or: class Test:
@deprecated(FUTURE_VERSION)
def deprecated_method(self):
return expected_return And finally I'd like to mention the docstring for the """Marks a function or method as deprecated.
A removal version must be supplied and it must be greater than the current 'pantsbuild.pants'
version.
When choosing a removal version there is a natural tension between the code-base, which benefits
from short deprecation cycles, and the user-base which may prefer to deal with deprecations less
frequently. As a rule of thumb, if the hint message can fully convey corrective action
succinctly and you judge the impact to be on the small side (effects custom tasks as opposed to
effecting BUILD files), lean towards the next release version as the removal version; otherwise,
consider initiating a discussion to win consensus on a reasonable removal version.
:param removal_version: The pantsbuild.pants version which will remove the deprecated
function.
:param hint_message: An optional hint pointing to alternatives to the deprecation.
:param subject: The name of the subject that has been deprecated for logging clarity. Defaults
to the name of the decorated function/method.
:raises DeprecationApplicationError if the @deprecation is applied improperly.
""" Multiple pants maintainers have expressed some interest in detaching the deprecation system there into a library anyone can use. Until then, I think these might be useful as reference material. |
Beta Was this translation helpful? Give feedback.
-
We need an official procedure for removing old versions of software.
Rationale
There are many reasons to remove old versions of software:
At the same time, there are many reasons to keep old versions of software:
Until LLNL hosts their own source/binary mirror that we can get download statistics from, we have no way of knowing whether or not old versions of software are actually in use. In the past, I've simply removed old versions, but I've gotten in trouble for doing this from users who still relied on that software.
Description
I propose the addition of the following syntax:
This is similar to the existing
preferred=True
parameter. For this parameter, I propose the following behavior:spack info
will only list non-deprecated versions (or add a "deprecated" tag)spack install
(and other commands that fetch) will print atty.warn
with the following behavior:--deprecated
flag similar to--no-checksum
for preserving the ability to do automated builds.This provides a means for warning users that old versions are no longer supported. If anyone complains that they still need this software, they should volunteer themselves to be package "maintainers" and remove the
deprecated=True
flag. If no one complains for a full release cycle, we can remove these versions from the package. If we want to be really explicit, we can adddeprecated=False
for things like Qt 3 which are required for older software.Additional information
Some PRs like #15420 help to mitigate this issue, but if we instead deprecate old versions and see if anyone uses them, we may find that legacy packages aren't needed most of the time. Once LLNL hosts their own source/binary mirror, we can at least tell how many people will be impacted, but we will still need a way of herding users to newer versions once the concretizer takes into account already-installed software. Even if older versions are still in use, I believe package maintainers/developers should have the right to stop supporting old versions of their software if no one else is willing to maintain it.
Another question worth discussing is if we want a way to deprecate entire packages (for example, when a duplicate package exists, or a package is renamed). By deprecating an entire package, we can prevent breaking changes from being merged until after a full release cycle. We can do this by either adding
deprecated=True
to every version, or addingdeprecated = True
as a package-level variable.@alalazo @tgamblin @scheibelp
Beta Was this translation helpful? Give feedback.
All reactions