Project

General

Profile

HOWTO do dev checkpoint releases » History » Version 5

« Previous - Version 5/9 (diff) - Next » - Current version
Abhishek Lekshmanan, 06/23/2017 12:55 PM


HOWTO do Checkpoint & RC Releases

Development checkpoint releases are essentially development snapshots released often until the first release candidate is announced. The process for development checkpoint releases are a bit more ad hoc compared to the formal processes involved for stable releases and for release candidates.

  1. Ask the ceph project lead, Sage on when to cut a release
  2. Until we stop diverging from master, which generally happens after one or couple of RC's always forward the master branch to the named release branch.
    This might require a release tag to be merged back to master, create a PR to do so, so as to ensure that the master is forwarded
  3. Prepare release notes. For RC releases this need to be done in advance, and requires input from all the leads
  4. Run the ceph-release-notes script on the release branch back to the previous dev. release
    $ ceph-release-notes --use-tags True -r v12.0.3..luminous for eg. 
    

This can be done in advance, just always add the commit hash of the commit you ran the script and then only the diff can be sorted and pasted back to the release notes. For eg

$  ./src/script/ceph-release-notes --token <mytoken> --use-tags True -r 9f259cb923e7474229bb2e5e54b59f3b7f068bc5..luminous . &> 12.1.0.rst

The UNKNOWN tags need to be edited to match the component, we're getting better with tagging all the PRs so this phase isn't as time consuming as before

  1. On approval, the <release> branch (for eg, kraken) in the ceph-releases repo (this is an exact copy of the ceph repo, only frozen in time in order to avoid commits between the time a release occurs and the long times package builds take place) would be used by the new build service, chacra to build packages. Alfredo triggers the build
  1. The final Release notes can be prepared based on this branch
  1. After successful build and a basic sanity test, the git tag is pushed to ceph-releases and ceph repo
  1. Ensure the packages are published and signed, check the locations in debian-<release-names> and rpm-<release-names> and the source tarball is uploaded as this is used for linking in the email to the list
  1. Once the builds are green and Alfredo gives the approval, announce a release as mentioned in HOWTO formally announce release, the rich view from the release notes rst rendering can be used to publish the blog post.