Checklist/XenHypervisorReleaseWithMarketing
|
This list contains a complete checklist for making a Xen Release, including PR |
Planning the Release
- Agree a rough schedule of RC's
- Plan and communicate a schedule of Checklist/Kicking_off_Test_Days
- Start establishing the list of features on publicity@lists.xenproject.org
- Reach out to Sarah Conway <sconway@linuxfoundation.org> to get started on the press release (takes about 4 weeks). Ideally Sarah ought to be contacted before we make the first RC
Making the Release
Step 1: See Checklist/XenHypervisorRelease
Step 2: Branch the codebase
Step 3: Publish source tarballs
Action Ian Jackson: Add instructions; Ian Jackson normally creates these
Publishing the release on the XenProject website
Step 4: Publish the tarballs on http://xenproject.org/downloads/xen-archives.html - this requires website admin rights and is done in the Docman component. Notes:
- If a new x.y release is created you will need to create a new category for the series http://xenproject.org/downloads/xen-archives/supported-xen-43-series.html. You may also need to rename older series such that they become unsupported in line with the following policy: Xen_Maintenance_Releases. Make sure you only change the page name, not the *slug* (called alias in Joomla terminology). Also make sure you do *not* have the text *supported* in any new *slugs* : we made that mistake in the past and now cannot change slugs without breaking incoming links without creating a redirect on the server (this cannot be done via the CMS UI).
- Create a new category for x.y.z (see http://xenproject.org/downloads/xen-archives/supported-xen-43-series/xen-430.html as an example).
- For x.y.0 releases, this contains links to release documents, documentation and contribution acknowledgement: check out the example. Note that the slug of the parent category is in the category.
- For maintenance releases, this category contains the changes to the prior release (see http://xenproject.org/downloads/xen-archives/supported-xen-43-series/xen-431.html)
- Create a document for the tarballs of the release and the signature : see the following examples
Step 5: Update the *Hypervisor Downloads* module to include a link to the latest release. Remove older ones as appropriate
Step 6: Announce on all developer mailing lists, user lists and the announce lists. Important note: these announcements must happen *after* the press release has gone out on the wire and the timing must be *coordinated* with the press team. Otherwise the release will not make a media impact.
Step 7: Publish blog post
Press Release
Step 1: Preparation and Approval
- About 2-3 weeks before the press release, a draft of the press release should be available. Ping Sarah Conway <sconway@linuxfoundation.org>
- The press release needs to be reviewed (by somebody who has a little experience)
- The press release needs to be approved by the Advisory Board. Sarah can drive this.
Step 2: Scheduling
- Before the release, agree a date with Sarah Conway <sconway@linuxfoundation.org> on when
- The press release gets sent out to the wire
- When journalists are pre-briefed
- Important note: the earlier of the dates above are a point of no return. The release must happen at this date
- Agree a live date and time : this is the time when
