Skip to end of metadata
Go to start of metadata

General description

The release process, as it is widely understood in Open Source,  can be described in the following bullet points:

  • Previous tasks
  • Acceptance tests
  • Release candidate declaration
  • License compliance verification (validation)
  • Pre-deployment testing
  • Gold Master declaration
  • Deployment
    • Deployment in the server and mirrors where is going to be downloaded it from.
    • Deployment tests. Verification and validation.
  • Publishing stage
    • Get URLs of downloadable files
    • Check downloads and instructions to installation and build new images.
    • Prepare download page.
    • Feature page: product description.
    • Marketing material: press kit, social media plan, merchandising...
    • Release announcement creation and publication.
  • Release support.
    • Critical updates release if needed.
    • Release impact analysis.
  • Publish a release summary.

Previous tasks to Gold Master declaration

There are key tasks that blocks the Gold Master declaration. They are the following ones:

  • Acceptance tests passed
    • One of the acceptance tests refers to naming the images and metadata with the right name, which should be self explanatory of what the image is about. The readme file and the documentation has to refer to it accurately so it is a step that has to be decided in advance and communicated.
    • Readme file updated. Readme file is shipped together with the image so it needs to be updated before declaring Gold Master
  • Release candidate declaration: there is no specific process today for this since only very recently images for deployment are available through

Gold Master declaration

Once the decision has been taken that a Release Candidate becomes a Gold Master, that is, the image to be released, the following actions will be taken:

  • Tag meta-genivi-dev on the last commit with a tag referring to the release.
  • Create the metadata associate to the image.
    • This process has now been transferred into a template which is used by multiple target dependant pipelines on, the XML of which is backed into git here (note this file is 'live' so is as such volatile to changes)
    • This is done by performing a build with 

      INHERIT += "archiver"
      ARCHIVE_MODE[src] = "original"
      COPY_LIC_DIRS = "1"
  • Make sure the metadata files are named including the port they are associated to, so they are easy to identify.
  • Sign metadata and image. (This is mostly scripted now, aims to be included in repo when applicable)
    • Source code: all the source code to be released. This is generated in tmp/deploy/source.
    • Yocto + OE Layers. This is provided by tarring up all the layers (and the conf in gdp-src-build) we use to build.
    • licenses.tar.gz: list of code including license and copyright text. This is generated in tmp/deploy/licenses.
    • license manifest: list of code with license associated. This is the file tmp/deploy/licenses/genivi-dev-platform-*/license.manifest
    • Package manifest: list of packages. This is generated in tmp/deploy/images.
    • image: The images are generated in tmp/deploy/images/$ARCH.
      • Special care has to be taken when producing the minnowboard image, as requiring users to use is unacceptable. Broadly, we create the image by doing (note genivi.go pipelines do not perform this due to sudo limitation): 

        dd if=/dev/zero of="$SDIMAGE" bs=1024 count=1M
        sudo losetup -d /dev/loop0
        sudo losetup /dev/loop0 "$SDIMAGE"
        sudo ../poky/scripts/contrib/ /dev/loop0 tmp/deploy/images/*/genivi-dev-platform-intel-corei7-64.hddimg /dev/mmcblk0 <<EOF
        sudo losetup -d /dev/loop0
        gzip "$SDIMAGE"
  • Place the images and metadata to be deployed in a secured location only accessible to deployers. (The aim is for a specific CI pipeline to eventually act as the middleman, see GDP-323  GDP-323 - Getting issue details... STATUS  )
    • The structure of the information should match the structure in the deployment environment, reducing the complexity of the deployment process.
    • Include the checksum file in the server.
  • Communicate the Gold Master location, ID and hash to the team.
  • Confirm release date/time. Communicate it.
    • PMO
    • Community management
    • Marketing
    • Operations

For more information, check the Gold Master declaration task of GDP 11 RC1 or RC2(GDP-379)( GDP-379 - Getting issue details... STATUS )

License compliance


This is the list of artifacts/metadata required for a license compliance verification by the LRT team are:

  • Images/binaries
    • Signed images declared Gold Master
  • Artifacts/metadata
    • SPDX-2 report from
      • Source code that has changed
      • All source code once the tools bugs has been fixed related with YOCTO and the infrastructure GENIVI has allows to upload and check the amount of data we produce (2Gb approx)
    • Source code: all the source code to be released.
    • Yocto + OE Layers
    • licenses.tar.gz: list of code including license and copyright text.
    • license manifest: list of code with license associated.
    • Package manifest: list of packages.

The above metadata should be provided in the download page, in a way that any user can associate it with the image simply.


  • In local.conf add the following lines
      INHERIT += "archiver"

             COPYLEFT_TARGET_TYPES = "target"

  • then perform a complete build. Then in  <image target>-<machine>-<timestamp> the license.manifest contains the required information.



General description of the deployment process:

  • Once Gold Master has been declared, so the images to be deployed are signed, a ticket with the following information is provided to GENIVI IT
    • Notify GENIVI IT where they can find all the archives to deploy for each target (in through a ticket, including the checksums 
      • Package Manifest
      • License Manifest 
      • Licenses
      • Yocto+OE layers
      • Sources

      • Checksum list
  • The ticket needs to be sent one to two days before the RD since they are big files and can get corrupted. So they need to be tested. Another reason is timezone differences between the GDP Delivery Team and GENIVI IT.
  • Once the ticket is reported as done, it needs to be checked through what it is called Deployment Tests:
    • Download every file.
    • Ensure the hashes are the correct ones. Images and metadata cannot be corrupted. Integrity test.
    • Test that the images run and that they can be built from scratch.
      • Use this step to test the instructions provided to users in the target wiki page.
  • If everything is correct, the ticket opened for GENIVI IT can be reported as closed.
  • Provide download links to editors so the correct links are included in the download page, social media messages and release announcement.
  • Verify that the tracking system works for both the archives to be downloaded and wiki pages related with the release, before RD
  • Ensure mirrors are being populated with the correct images and all the metadata. (not applicable to GENIVI)
  • Communicate to GENIVI management that the deployment has finished.

For more information, please check any Pre-deployment task of any of the releases, like GDP 11 RC2, for instance(GDP-380 & GDP-381)( GDP-380 - Getting issue details... STATUS and GDP-381 - Getting issue details... STATUS )


  • Get URLs of downloadable files from the ticket sent by GENIVI IT.
  • Check downloads and instructions to install and build new images one more time.
  • Redirection (links)
    • Since GENIVI URLs are so complicated, GDP team works with redirections to the most important pages. The list of redirections is in the GDP Management wiki page.
    • Before each release, the new redirections need to be sent to GENIVI IT to include them in the DNS. OSSINFR-90  OSSINFR-90 - Getting issue details... STATUS
    • Remember that one redirection that needs to be changed on every release is the Release Announcement one.
    • The redirections need to be tested.
  • Prepare download page.
    • Add information, hashes and links to the files/images to be download.
    • Test the links.
  • Prepare feature page: product description. GDP-384  GDP-384 - Getting issue details... STATUS
    • Verify all links.
  • Prepare marketing material
    • Create web version of the release announcement. GDP-309  GDP-309 - Getting issue details... STATUS
      • Create the release announcement in GENIVI blog.
      • Send it to GENIVI marketing for verification/approval.
      • Clone it using Confluence macro for cloning wiki pages in GDP blog
    • Create the mail version of the release announcement
    • Create the social media page.
      • Create social media messages and ping Linda about them.
    • Prepare press kit (no done so far in any release)
  • Communicate GENIVI management and marketing that we are ready to Release on RD/RT
  • Publish Release announcement. GDP-347  GDP-347 - Getting issue details... STATUS
  • Track the release. GDP-348  GDP-348 - Getting issue details... STATUS

Release announcement creation

You can find a description of what the Release announcement is in the Content section below.

  • Release announcement should be done as soon as Gold Master is declared in order to be checked by marketing and included in the press kit.
  • The right title should be selected before defining the redirection link. If you change the title of the release announcement, Confluence will change the URL so the redirection won't work.
  • It will be done in a blog page on Confluence with restricted access to people that will review it.
  • The release announcement should focus on downloading the image, so especially the download page link should be double checked before it is published.
  • The link to the Release Announcement should be known in advance so messages from the social media campaign can point to it, as well as translations, before RD (Release Date).
    • For GDP, the release announcement link is:
    • Once the release announcement is done, a ticket at OSSINFR has to be opened requesting the redirection of the above link to the release announcement, once approved by GENIVI Marketing.
    • Check OSSINFR-28  OSSINFR-28 - Getting issue details... STATUS as example.

Other contents

  • Labels at wiki and bug tracker to match the new version, following the policy described in GDP Management page.


The following picture reflects the content structure that has been defined for the GDP project. Each post-it can have associated more than one wiki page but this is only an attempt to provide a high level view of what is actually on the wiki.

The content critical path for GDP releases is the expected journey through GDP contents that a newbie will go through (expected). In GDP, this path is as defined in the graph.



It is required to evaluate the analytics put in place in our wiki to find out if the expected behaviour is there or not, in which case the problems should be found and fixed. You can access to the .pdf version of the above images attached to this page.


Readme file

On each release, the Readme file should be updated to reflect the new links, contents, support channels etc that are new compared to the previous release. Also the links to relevant technical information like layers dependencies and targets. Examples: Readme file for GDP-ivi9 beta.

In GitHub, is the default info page unless you create one specifically as home page. GDP is using for now so an introduction with relevant links has been added.

Known issues

For each release, in different pages (target pages and feature page) there are links to known issues tickets. Known issues are those bugs or problems that the software released has and has not been fixed before the release.

The tickets referring to those issues normally have many comments that describe the evolution of the ticket. A new user that approaches them from the target pages when they are building or running GDP demands a fixed picture of those issues. The last comment of the ticket must be a summary of the current state of the issue and its impact. If it is not there, and usually is not, it should be created for the release.

The known issues should be linked in the feature page. Issues specific to a particular target should be also linked in the target page.


In order to create demand, one or more articles should be created and published before the release, talking about what is expected in the release. The main idea is to promote early adoption and testers, as well as advancing the release itself.

Examples: openSUSE 13.1 pre-release article

Press kit (not done)

  • Press announcement
  • Release announcement preview
  • Product highlights (PDF)
  • Screenshots (include 'exclusive/extra' screenshots)
  • A link to the image (preview)
  • VIP quotes.
  • Contact for interview, questions about the product, etc.

On Release Date

The GDP release should include the following contents:

  1. Release announcement
  2. Download page
  3. Social media messages

Release announcement

The release announcement is a wiki page that includes all the relevant information and links related with the new product. It should include, at least, the following:

  • Key sentence/message: short and highlighted
  • Links to the translations of the release announcement
  • Main strengths and news about the release in 2 or 3 paragraphs.
  • VIP quotes.
  • How to get the image released.
    • How to report bugs.
    • How to contact maintainers.
    • How to upgrade from previous version.
  • Thanks section.
  • Further description of the main news/strengths. Include screenshots.
  • About GENIVI section.

Examples: openSUSE release announcement

The text should be validated by the GENIVI community manager and the Program manager before being published.

Social media messages

Tips for coordinators and contributors:

  • When the social media messages are created, the wiki pages with the release content should be already created, although might not be published. Those links must be known and included in the original social media messages, before they are translated.
  • Social Media messages should include links to the contents that describe or reinforce the key messages: feature description, highlights, announcement, download page....
  • Hashtags must be agreed and carefully placed. Translators should consider adding reference to content in their own language.
  • Messages should be slightly different for different social media.
  • Create specific article for slashdot alike pages so it can also be translated since most countries have these kind of collaborative news portals.
  • Pictures are very welcome. Screenshots should be taken for each release and include them in social media messages when appropriate.
  • Translation is not an easy task. Provide the social media messages in English at least 48 hours prior to Release Time (RT) and ping translators so they have enough time.
  • The messages in English should be verified before translators jump in. Revert any mistake once the messages are translated this might not be possible.
  • Admins of social media accounts should be briefed prior to the release on what to do.
  • Contributors should know about the social media messages and how to promote them before the campaign starts. Include the instructions in the wiki page where the messages are listed.

Examples: openSUSE social media launch plan

Check the social media plan for GDP-ivi9 releases.

Post release

Release summary (not done before)

The summary of the release should contain data that provides an idea of the impact of the release together with the highlights from the team and the press coverage. This summary should be published RD+31 days

Minimum data:

  • Downloads the first day / week / month
  • Comparative with the same data from previous releases.
  • Hits and unique visitors of the release announcement and download page.
  • Social media impact.
  • Analysis of the data
  • Bugs open/processed fixed/closed during the release process.

Highlights from the team

  • Lessons learnt
  • Points to be improved for next release and actions to be taken.
  • Improvements from previous releases.

Press coverage

  • Media that published info about the release.
  • Significant opinions about the product.