-
Notifications
You must be signed in to change notification settings - Fork 18
/
package-end-of-life.Rmd
155 lines (115 loc) · 6.44 KB
/
package-end-of-life.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
# Package End of Life Policy
The Bioconductor project strives to provide a software repository that is
stable and relevant to users across the community. Each year about 100-150 new
software packages are added to the repository; as of Spring 2021 over 2000
packages are hosted. The Bioconductor Build System (BBS) installs, builds, and
checks each software package every 24 hours. Regular execution of example,
vignette, and unit test code ensures the package is operating as expected and
all required dependencies are available. The [build system][build reports]
provides a detailed report for each package across three platforms: Linux,
Windows, and Mac.
In an effort to maintain a high quality repository we have adopted a
one-year end of life (EOL) process for packages that no longer pass
build or check and do not have an active maintainer. Packages are
assessed for EOL deprecation prior to each Bioconductor release; the
EOL policies apply to software, annotation, workflow, and experiment data
packages.
## Criteria for package deprecation by Core Team
1. R CMD build or check errors on one or more platforms
The package must build and check without error on all platforms
(exceptions to cross-platform builds are available under limited
circumstances) at each Bioconductor release. All efforts will be
made to keep a package in the repository if the maintainer is
actively attempting a fix.
If a package is broken for an extended period of time the maintainer will
be given a final 2 week notice. If the package is not fixed by the end
of the 2 weeks, End of Life will be started.
2. Inactive maintainer
The maintainer listed in the DESCRIPTION file must be responsive to
questions on the support site, package-related email from users and
Bioconductor team members, package-related errors in the build
system, and requests for bug fixes. The email in the DESCRIPTION must also
remain a valid, active email.
## User Requested Deprecation
Alternatively, a package maintainer may request package deprecation. The
maintainer may have any number of reasons for deprecating their package. Some
common reasons include:
1. They no longer wish to maintain their package
2. The package functionality has been superseded by other packages
3. The package material has become out-of-date and it makes sense to retire the
package.
4. Significant changes to the underlying technology e.g., a web API, have made
the package unmaintainable.
We ask that maintainers wishing to deprecate their package send an email
notification to [bioc-devel][bioc-devel-mail] mailing list. The core team will
ensure all necessary steps and notifications can occur.
## End of Life process
**Step I**: Deprecation
Packages to be deprecated will be marked with a deprecation warning and the
package name will have a strikethrough on the build report. The warning is
emitted when the package is loaded, and is reported on the package 'landing
page'. The message alerts users that the package currently fails the minimal
build and check criteria, and that the package will likely be removed from
Bioconductor in the next release.
If at any time in this 6 month period the required criteria are met (e.g., the
package returns to active maintenance, perhaps after 'adoption' by a third
party) the warning is removed.
**Step II**: Defunct
When a package has gone through one development cycle as 'deprecated' without
remedial action, the package is marked as 'Defunct'. The package is removed
from the nightly build system, is no longer available through
'BiocManager::install()', and does not have a current 'landing page'.
The package remains available in the git archive, and in previous
versions of Bioconductor.
Defunct packages cannot re-enter the Bioconductor repository except through
review as a 'new package'.
**Example**:
A package identified for deprecation during Bioconductor release 3.2 /
devel 3.3 would make the following transitions:
- deprecate in devel 3.3
** Bioc Release **
- deprecate in release 3.3 (i.e., no change in release status)
- defunct in devel 3.4
** Bioc Release **
- defunct in release 3.4
- gone in devel 3.5
** Bioc Release **
- gone in release 3.5
## Implementation detail
1. Notify the bioc-devel mailing list and maintainers of packages
Depending, Importing, or Suggesting the package that the package
will be deprecated. If appropriate, indicate that a new maintainer
is welcome to take over.
2. Add the following code chunk to the 'devel' version of the package
in a file `R/zzz.R`, adjusting the Bioconductor version to the
version _after_ the current devel version.
.onAttach <- function(libname, pkgname) {
msg <- sprintf(
"Package '%s' is deprecated and will be removed from Bioconductor
version %s", pkgname, "3.4")
.Deprecated(msg=paste(strwrap(msg, exdent=2), collapse="\n"))
}
3. Add the following annotation to the package DESCRIPTION file.
PackageStatus: Deprecated
4. The package remains deprecated in the 'devel' branch for up to 6
months, after which time Bioconductor core
team members remove the package from the 'devel' package manifest.
## Reversing End of Life Status
A deprecated package can be un-deprecated and removed from the End of Life
process if it is fixed before the next Bioconductor release. To have a
package un-deprecated, please contact [email protected]. If a package
is already in the defunct stage; the package will mostly likely be requested to
go through the new package submission process again.
## 'Orphaned' packages
An 'orphaned' package is a Bioconductor package with an inactive and
non-responsive maintainer. As described above, Bioconductor makes multiple
efforts to reach out to package maintainers to fix broken packages. If there is
no response from a maintainer to the emails sent out from the core team, the
package is considered 'orphaned'. Occasionally, members of the Bioconductor
community reach out to take over maintenance of an 'orphaned' package. The
interested replacement maintainer is asked to email the original maintainer and
[email protected], to formally request permission to take over. Unless
there is an explicit request for a package to be retired, Bioconductor will
grant access to the interested replacement maintainer in accordance with open
source software licenses that Bioconductor packages require and
[package naming policy](#naming) that maintainers agree to upon submission.