This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Release statuses

Whether and how you should use a specific version of ready4 software depends in part on its release status.

1 - Unreleased code

Some work in progress code has yet to be publicly released or fornmally acknowledged as part of the ready4 suite.

Currently, a new ready4 software project initiated by the ready4 core team will by default be made public as a pre-release version in the ready4 GitHub organisation. However, there are some important exceptions. Principally, these exceptions relate to code that we authored in the initial phase of ready4’s development to which some or all of the following apply:

  • the code is highly unstable because it has not been (fully) updated to account to major changes implemented in core dependencies;
  • the code uses outdated naming conventions and is potentially confusing when used in conjunction with other elements of the ready4 suite; and/or
  • the code repository has yet to be cleansed of artefacts that are not yet appropriate for public dissemination (e.g. renders of draft scientific manuscripts).

Depending on which of the above issues apply to a code repository, that repository will either be:

  • a private repository (not accessible to anyone outside the core development team); or
  • a public repository stored in a location other than the ready4 GitHub organisation.

2 - Development releases

Development releases provide the most comprehensive and up to date public record of a ready4 project’s source code but may be poorly documented and tested.

A complete record of all publicly available versions of a ready4 software project’s code over its entire development history (including the most up to date version) is stored in the ready4 GitHub organisation. We refer to these comprehensive publicly available source code resources as “development releases” (even though these records will include versions of our code that we have not formally labelled as “releases”).

Public access to development releases allows individuals to install, test and preview code in advance of production versions being released. Development releases also provide transparency as to who contributed what to a software project and when these contributions were made. Accessing the latest development version of the code is particularly useful to people who wish to contribute bug fixes or new features to our code.

Limitations of development releases include the likelihood that some or all of this code may be inadequately documented or tested. In peer reviewed publications, it is generally considered preferable to avoid citing the copies of code stored in GitHub repositories as these repositories are impermanent (they can be moved, renamed or deleted at any time).

3 - Production releases

Production releases are the versions of software intended for end-users.

Production releases of our code are intended for end-users and signal that they have undergone a number of quality assurance checks and have some supporting documentation.

We have yet to make any production releases of ready4 software, but plan to do this in 2023. Production releases of ready4 R packages will be submitted to CRAN. Unless and until a software item is submitted to a production code repository like CRAN, the recommended platform from which to install our software is that software’s GitHub repository.

4 - Archived releases

Archived releases are permanent, uniquely identified records of key project milestones.

Software items that we have formally issued as “releases” are archived as permanent, uniquely identified (with DOI) and citable records within the ready4 Zenodo community. Archived releases of ready4 software are useful as they are snapshots of a project at key milestones in its development (e.g. at the time an analysis was undertaken). As these milestones are purposely selected, archived releases are more likely to have undergone some testing and documenting prior to being released than code not selected for release.

A limitation of archived code libraries is that a greater knowledge of R is required to appropriately install R packages from Zenodo compared to the simpler installation process for the versions of code libraries stored on either GitHub or CRAN.