HOWTO start working on a new point release » History » Revision 16
Revision 15 (Loïc Dachary, 03/06/2021 12:33 PM) → Revision 16/18 (Loïc Dachary, 03/06/2021 12:36 PM)
h3. Create a new version * http://tracker.ceph.com/projects/ceph/versions/new * only set the name with **release version** (for instance **v0.80.10**) * select *Shared with subprojects* h3. Decide who will drive the point release There is no formal process. Someone volunteers and discuss it with [[HOWTO#Whos-who|other members of the team]], via e-mail or irc. h3. Create new task * http://tracker.ceph.com/projects/ceph-releases/issues/new * Title *release version* (for instance **firefly v0.80.10**) * Assign it to the "backporter":http://tracker.ceph.com/projects/ceph-releases responsible for it * Set the *Affected Versions* field to the version (for instance **v0.80.10**) * Set the priority to *Urgent* for releases that contain only a few backports that need to be published immediately and *High* otherwise h3. Add a workflow section to the description The issue is used to figure out at what point of the release workflow it currently is. The "development workflow":https://docs.ceph.com/en/latest/dev/development-workflow/ workflow":http://ceph.com/docs/master/dev/development-workflow/ must be copied and edited to reflect the specifics of the version being released (i.e. replacing roles by names of people responsible for a given component at this point in time for instance). Here is an example from "nautilus v14.2.17":https://tracker.ceph.com/issues/49629 "firefly v0.80.10":http://tracker.ceph.com/issues/11090 h3. Workflow * "Preparing the release":https://docs.ceph.com/en/latest/dev/development-workflow/#preparing-a-new-release *TBD* release":http://ceph.com/docs/master/dev/development-workflow/#preparing-a-new-release * "Cutting the release":https://docs.ceph.com/en/latest/dev/development-workflow/#cutting-a-new-stable-release release":http://ceph.com/docs/master/dev/development-workflow/#cutting-a-new-stable-release ** Abhishek/Yuri Loic asks Sage if a point release should be published ** Loic gets approval from all leads *** Yehuda, rgw: *** Casey, rgw - *TBD* Gregory, CephFS: *** Patrick, fs - *TBD* Josh, RBD: *** Jason, rbd - *TBD* Sam, rados: *** Neha, rados - *TBD* ** Abhishek Sage writes and commits the release notes ** Loic informs Yuri that the branch is ready for testing - sha1: Current SHA1: see in note below ** Yuri runs additional integration tests - *TBD* *** ** If Yuri discovers new bugs that need to be backported urgently (i.e. their priority is set to *Urgent* or *Immediate*), *Urgent*), the release goes back to being prepared; prepared, it was not ready after all ** Yuri informs Sage, David Alfredo that the branch is ready for release - *TBD* ** Someone Alfredo creates the packages and sets the release tag - *TBD* ** Someone writes and commits the release notes - *TBD* ** Someone sends out release announcement email - *TBD* ** Someone posts release announcement on https://ceph.com/community/blog - *TBD* h3. Release information ** branch to build from: nautilus, commit: ** version: v14.2.17 ** type of release: point release ** where to publish the release: http://download.ceph.com/ h3. Add a release information template to the description This will be used by the person responsible for the publishing the release. Although it is largely redundant with information from the context, it can convenientely be copy pasted and does not require any understanding of the conventions used for backporting. The release manager can publish the release with just this information and nothing else. The commit hash (**???**) below is in the release branch and has "received approval by everyone involved":http://ceph.com/docs/master/dev/development-workflow/#cutting-a-new-stable-release * branch to build from: firefly, commit:??? * version: v0.80.10 * type of release: point release * where to publish the release: http://download.ceph.com/debian-$release and http://download.ceph.com/rpm-$release