- Types of Packages
- Package Naming Policy
- Author/Maintainer Expectations
- Experiment data package
- Annotation package
- Workflow package
- Review Process
- Following Acceptance
- Additional Support
To submit a package to Bioconductor the package should:
- Address areas of high-throughput genomic analysis, e.g., sequencing, expression and other microarrays, flow cytometry, mass spectrometry, image analysis; see biocViews.
- Interoperate with other Bioconductor packages by re-using common data
structures (see Common Bioconductor Methods and Classes) and
existing infrastructure (e.g.,
rtracklayer::import()for input of common genomic files).
- Adopt software best practices that enable reproducible research and use, such as full documentation and vignettes (including fully evaluated code) as well as commitment to long-term user support through the Bioconductor support site.
- Not exist on CRAN. A package can only be submitted to one or the other.
- Comply with Package Guidelines.
- Your package cannot depend on any package (or version of a package) that is not (yet) available on CRAN or Bioconductor. The package should work with whatever current version of the package is publically available.
Software Packages. Most packages contributed by users are software packages. Software packages provide implementation of algorithms (e.g. statistical analysis), access to resources (e.g. biomart, or NCBI) or visualizations (e.g. volcano plots, pathways plots). Instructions for creating Software packages can be found here: Package guidelines.
Annotation packages are database-like packages that provide information linking identifiers (e.g., Entrez gene names or Affymetrix probe ids) to other information (e.g., chromosomal location, Gene Ontology category). It is also encouraged to utilize AnnotationHub for storage and access to large raw data files and their conversion to standard R formats. Instructions for adding data to AnnotationHub and designing a annotation package to use AnnotationHub can be found here: Create A Hub Package.
Experiment data packages provide data sets that are used, often by software packages, to illustrate particular analyses. These packages contain curated data from an experiment, teaching course or publication and in most cases contain a single data set. It is also encouraged to utilize ExperimentHub for storage and access to larger data files. ExperimentHub is also particularly useful for hosting collections of related data sets. Instructions for adding data to ExperimentHub and designing an experiment data package to use ExperimentHub can be found here: Create A Hub Package.
Workflow packages contain vignettes that describe a bioinformatics workflow that involves multiple Bioconductor packages. These vignettes are usually more extensive than the vignettes that accompany software packages. These packages do not need man/ or R/ directories nor a data/ directory as ideally workflows make use of existing data in a Bioconductor package. See development section on Workflows for more details.
See Package Guidelines for details on package format and syntax.
Ownership of package name. Bioconductor follows CRAN’s policy in requiring that contributors give the right to use the package name to Bioconductor at time of submission, so that the Bioconductor team can orphan the package and allow another maintainer to take it over in the event that the package contributor discontinues package maintenance. See Bioconductor’s package end-of-life policy for more details.
Uniqueness of package name. Packages should be named in a way that does not conflict (irrespective of case) with any current or past BIOCONDUCTOR package, nor any current or past CRAN package.
See Package naming guidelines for more guidelines.
Read and follow the full Contributor Guidelines section.
Submit by opening a new issue in the Bioconductor Contributions repository, following the guidelines of the
README.mdfile. Assuming that your package is in a GitHub Repository and under the default branch, add the link to your repository to the issue you are opening. You cannot specify any alternative branches; the default branch is utilized. The default branch must contain only package code. Any files or directories for other applications (Github Actions, devtool, etc) should be in a different branch. If you are submitting two highly related packages or circular dependent packages please see here. The lighter dependent or package that can be installed without a dependency should be submitted first; this is generally the associated data package to a software package.
Experimental data packages contain data specific to a particular analysis or experiment. They often accompany a software package for use in the examples and vignettes and in general are not updated regularly. If you need a general subset of data for workflows or examples first check the AnnotationHub resource for available files (e.g., BAM, FASTA, BigWig, etc.) or ExperimentHub for available processed example data set already included in Bioconductor. If no current files or data sets are appropriate consider an associated Experiment Data Package that utilizes ExperimentHub.
If you have an associated data package for your software package, please do NOT create a separate issue in the our tracker repository for that. Instead, please add the data package repository to the same issue as the software package. The process for doing this is documented here. Generally the data package should be submitted first.
Annotation packages contain lightly or non-curated data from a public
source and are updated with each Bioconductor release (every 6
months). They are a source of general annotation for one or many
organisms and are not specific to a particular experiment. When
possible, they should support the
select() interface from
Annotation packages should NOT be posted to the tracker repository. Instead send an email to firstname.lastname@example.org with a description of the proposed annotation package and futher instructions of where to send the package will be provided. Whenever possible Annotation Packages should use the AnnotationHub for managing files.
Workflow packages contain vignettes that describe a bioinformatics workflow that involves multiple Bioconductor packages. These vignettes are usually more extensive than the vignettes that accompany software packages. These packages do not need man/ or R/ directories nor a data/ directory as ideally workflows make use of existing data in a Bioconductor package. See development section on Workflows for more details
A new package is initially labeled as
1. awaiting moderation. A Bioconductor team member will take a very brief look at your package, to ensure that it is not doing anything malicious or inappropriate. Packages that pass this stage will be labelled
The moderator will add your package as a repository to the git.bioconductor.org git server, copy the SSH keys from your github account to the BiocCredentials application application and the issue labelled
ALL CHANGES TO YOUR PACKAGE must be pushed to the git.bioconductor.org repository created in this step. See the New package workflow for instructions on pushing changes to your git.bioconductor.org repository.
The package will be submitted to the Bioconductor build system (BBS). The system will check out your package from GitHub and move it to our git.bioconductor.org git server. Please familiarize yourself with git as the git.bioconductor.org is the versions the (BBS) will always use. It will then run
R CMD buildto create a ‘tarball’ of your source code, vignettes, and man pages. It will run
R CMD checkon the tarball, to ensure that the package conforms to standard R programming best practices. Bioconductor has chosen to utilize a custom
R CMD checkenvironment; See R CMD check environment for more details. Finally, the build system will run
BiocCheck('new-package'=TRUE)to ensure that the package conforms to Bioconductor BiocCheck standards. The system will perform these steps using the ‘devel’ version of Bioconductor, on three platforms (Linux, Mac OS X, and Windows). After these steps are complete, a link to a build report will be appended to the new package issue. Avoid surprises by running these checks on your own computer, under the ‘devel’ version of Bioconductor, before submitting your package.
If the build report indicates problems, modify your package and commit changes to the git.bioconductor.org version of your package as described in the new package git workflow. If there are problems that you do not understand, seek help on the bioc-devel mailing list.
To trigger a new build, include a version bump in your commit, e.g., from
Version: 0.99.1. Pre-release versions utilize the
0.99.zformat. When accepted and released, your package’s version number will be automatically incremented to 1.0.0.
If in the pre-review process there are identified larger issues with the package, a label
3e. pending pre-review changesor a more specific flag of package issue will be assigned. Please address any pre-review identified issues and comment back for the package admininstrators to re-evaluate.
Once your package builds and checks without errors or (avoidable) warnings, the package is assigned a reviewer. The package will be labelled
2. Review in progress.
The reviewr will provide a technical review of your package. Other Bioconductor developers and users with domain expertise are encouraged to provide additional community commentary. Reviewers will add comments to the issue you created.
Please be courteous with your package reviewers and always follow the Bioconductor Code Of Conduct with correspondence. Please allow 2-3 weeks for reviewers to assess your package.
Respond to the issues raised by the reviewers. You must respond to the primary reviewer, and are strongly encouraged to consider community commentary. Typically your response will involve code modifications; commit these to the default branch of git.bioconductororg. When you have addressed all concerns, add a comment to the issue created in step 2 to explain your response.
The reviewer will assess your responses, perhaps suggesting further modifications or clarification. The reviewer will then accept your package for inclusion in Bioconductor, or decline it. The label
2. review in progresswill be replaced by
If your package is accepted, it will be added to Bioconductor’s nightly ‘devel’ builds. All packages in the ‘devel’ branch of the repository are ‘released’ to the user community once every six months, in approximately April and October.
Once the review process is complete, the issue you created will be closed. All updates to your package will be through the Bioconductor Git Server.
Please be mindful that reviewers are volunteers and package reviews are not the only responsibility of Bioconductor team members. We like to see the review process progress by updates from the submitter or by comments from the reviewer within 2-3 weeks. The entire review process typically takes between 2 and 6 weeks. If there is no response after 3 to 4 weeks, package reviewers may close the issue until further updates, changes, and/or commentary are received.
Following acceptance of a package:
- Packages accepted on the tracker repository are added to the ‘devel’ branch of the Bioconductor GIT repository, with the current version number of the accepted package.
- Packages are then built by the Bioconductor nightly build
process. On-demand builds of accepted packages do not occur. Please see the
build reports for how often the different package types are built. The
changes pushed to a ‘devel’ version of a package can take up to 24-28 hours to
appear. See build timings. If the build is successful, the package has its own
‘landing page’ created, and the package is made available to users
of the ‘devel’ branch of Bioconductor via
- Changes to their package (if any), should be done to version in the Bioconductor git server.
- Developers should bump the
zportion of their version number every time they commit changes to their package, following the Version numbering guidelines. If developers don’t bump the version, the changes made to their package do not propagate to the Bioconductor web site and package repository.
- Devlopers should make sure the maintainer email in the DESCRIPTION stays accurate and reachable.
We are eager to enhance the quality and interoperability of Bioconductor software and will provide additional support when requested by package developers. Example areas of assistance include use of appropriate S4 structures, specific guidance on efficient implementation, guidance on code structure, and critical assessment of package documentation and structure. Use the bioc-devel mailing list or email email@example.com to obtain additional support.
- Support Email: firstname.lastname@example.org