Skip to content

Latest commit

 

History

History
67 lines (50 loc) · 4.41 KB

OpenSC-Release-Howto.textile

File metadata and controls

67 lines (50 loc) · 4.41 KB

OpenSC Release Howto

Releasing OpenSC should be simple and streamlined, yet a predictable and easily repeatable process. This page describes releasing OpenSC from Git.

Generic Principles

At least one (or more, if needed) pre-releases must be done before the actual release. After a release candidate has been published, no more merges to the master branch should happen, only release-critical single commits can be cherry-picked and a new release candidate created. Normal development should continue when the final release is done.

Preparing Security Relevant Changes

Release Preparations

On Github:

In Version Control

Release (or RC) version must be changed in the following files:

  • NEWS (Markdown)
  • configure.ac : change package version major/minor/fix as needed, RCs get the package suffix `-rc`, which is removed for the final release
  • configure.ac : Update the LT version number
  • .appveyor.yml: Update the version on first line

Optionally, discuss changes to NEWS by opening a new issue with your suggestions.

Build and Test Binaries

  • Wait around 10 minutes to allow build artifacts be placed into the nightly builds. All builds must succeed and must not generate more warnings than the previous build.
  • Copy build artifacts selecting the correct branch using the hash of the release commit, e.g.:
      git clone https://github.com/OpenSC/OpenSC --single-branch
  cd OpenSC
  BRANCH=`git log --max-count=1 --date=short --abbrev=8 --pretty=format:"%cd_%h"`
  wget https://github.com/OpenSC/Nightly/archive/${BRANCH}.zip
  unzip ${BRANCH}.zip
  • Download the MacOS installer from the Github Actions OSX CI for a tag and attach it to the release on github
  • Do a separate smoke test for all installers and the tarball, document your results in the Wiki.
  • If creating a final release, create an annotated tag instead of a lightweight tag:
      git tag -a 0.20.0
  git push origin 0.20.0
  • Create a new (draft) release
  • For final releases, select the existing tag, e.g. 0.20.0; for release candidates choose a new tag, e.g. 0.20.0-rc1, which Github will automatically create as lightweight tag.
  • Describe the release including all changes to NEWS (Markdown)
  • Upload the build artifacts to the new release
  • Check This is a pre-release if only creating a release candidate

Announcement

  • Write announcement. Write short human readable version
  • Short overview of OpenSC
  • Important and visible (breaking) changes in this release (not a copy of NEWS file)
  • URL-s for downloads
  • Pointers to full verbose information (list of commits, full changelog, closed bugs)
  • Plans for next release
  • Find someone to proofread the announcement.
  • Via mail publish the announcment on [email protected] and [email protected] lists.
  • In case of security relevant changes, forward the announcement to [email protected]
  • Update the Main Wiki page with links to new release

Clean up old nightly builds repository

The repository https://github.com/OpenSC/Nightly is used to hold nightly builds for both MacOS and Windows. They are pushed on every master commit so the old builds need to be cleaned up regularly. Ideally after the new release is done, any old branch before last release can be removed through the github web UI on https://github.com/OpenSC/Nightly/branches/stale. For more info, see the OpenSC/Nightly#1