Skip to content

Release Management

Jump to bottom Edit New page
Rand McKinney edited this page Aug 21, 2023 · 4 revisions

This page documents the process for creating a DASH.js release. dash.js creates two kinds of releases:

  • Release Candidate (RC) is an interim release that has been tested by the developers but not yet approved by the DASH-IF Interoperability Working Group. These releases are intended for development use. There will typically be a number of Release Candidates between each approved DASH-IF release. The latest release candidate is always available on our demo site
  • Reference Implementation Release (Release) is a release that has been validated by the DASH-IF Interoperability Working Group. These releases are considered to be official reference implementations of the DASH-AVC/264 Interoperability Specifications.

This page documents how this approval is sought and, once provided, how a formal release of the DASH.js code is made.

Process for production of a Release Candidate

This section describes the process for creating a release candidate. A release candidate is a release that has not been validated by the Interoperability Working Group. It is intended for developers and for demonstration of future releases from the DASH-IF. There will be a number of Release Candidates for each DASH-IF release where each release candidate adds important features and stability improvements as the community works towards an official DASH-IF release of the reference player.

  1. Development:
    1. Agree the features that will be in the upcoming release.
    2. Record in the issue tracker under the appropriate milestone.
    3. Create a feature branch for each major feature.
    4. Minor changes can be made in hotfix branches.
    5. Request review of feature branches to be included:
      • Record issues in the issue tracker.
      • Reviews must include a License Audit and Legal Audit - including headers, dependencies, LICENCE and NOTICE files.
      • After successful review, merge the feature branch into the "development" branch.
      • The review period lasts for a minimum of 72 hours (allow for weekends and other breaks).
    6. When all feature branches have been merged into the development branch and no blocking issues in the issue tracker are remaining, the release process can start.
  2. Prepare for release:
    1. Bump the version number in the "development" branch.
    2. Conduct a license Audit and Legal Audit - including headers, dependencies, LICENCE and NOTICE files.
    3. Documentation – Check installation and build documentation for accuracy, create status document, create release notes.
    4. Call for developers to test the development branch. NOTE: From this moment until development branch is merged into master, only bug fixes are allowed in the development branch.
    5. Call a vote for the release.
  3. Create release candidate:
    1. Merge the development branch into master.
    2. Tag master.
    3. Build the release packages .
    4. Write the release announcement.
  4. Release candidate publication:
    1. Upload release files to the demo site.
    2. Update the website:
      • News item
      • Demo updates
    3. Announce the release.
  5. If this release is to be considered by the Interoperability Working Group, start the Release Process defined below.

Process for preparation of a Reference Client Release

This section describes the process of moving a Release Candidate to full reference client status. That is it describes the process by which the DASH-IF Interoperability Working Group approve a release candidate for formal release. A formal release is an official reference implementation of the DASH-AVC/264 interoperability specifications.

  1. Invite the Interoperability Working Group (IWG) to review the latest Release Candidate.
  2. IWG test and review the release candidate:
    1. Issues are reported to the dash.js development team.
    2. Issues raised are recorded by the dev team in the issue tracker and given appropriate severity flags.
    3. Reviews must include a License Audit and Legal Audit - including headers, dependencies, LICENCE and NOTICE files.
    4. The review period lasts for a minimum of 120 hours with at least 240 hours being preferred (allow for weekends and other breaks, e.g. 5 working days minimum, 10 working days optimum.)
  3. If any blocking issues were recorded, the Reference Client release is aborted and a new Release Candidate process is started. If no blocking issues were recorded the Reference Client is released as follows:
    1. Prepare for release:
      1. Bump the version number in the development branch
      2. Documentation – Check installation and build documentation for accuracy, create status document, create release notes
    2. Create Reference Client release package:
      1. Merge the development branch into master
      2. Tag master
      3. Build the release packages
      4. Write the release announcement
  4. Reference Client publication:
    1. Upload release files to the demo site.
    2. Upload the files to the official release site.
    3. Update the dash.js website.
      • News item.
      • Demo updates.
    4. Announce the release.
Add a custom footer
Add a custom sidebar
Clone this wiki locally