ReleasePolicy

From Openmoko

Revision as of 06:28, 16 March 2010 by Glenn (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Openmoko Software Distribution Release Policy

  • Set distribution version (DISTRO_VERSION)
  • Set DISTRO_TYPE to release. This is important. It will zap the root password, disable password less root log-in for ssh, disable debugging
  • Start a build
  • Do final testing by QA
  • Make a backup of the buildhost for future reference (point is to be able to restore it...)
  • Sign kernel, uboot, rootfs, Packages files, QA report, OE version of the build (git-tag and push) using FIXME key
  • Upload kernel, uboot, rootfs, feed to FIXME
  • Upload sources used to build the distribution to FIXME
  • Publish instruction and announcement (press...).


Openmoko component/project Release Policy

  • Set the right version number (X.Y.Z)
  • Create a branch projectname-X.Y (if it doesn't exist)
  • Create a tag projectname-X.Y.Z
  • Change version numbers
    • X.Y+1.0 for the main development (or higher)
    • X.Y.Z+1 for the branch
    • Make sure bugtracker gets at least X.Y entry as version
  • Create tarball, create GNU pg signature, upload to standard place (http://downloads.openmoko.org/)
  • Send release notice somewhere
Personal tools

Openmoko Software Distribution Release Policy

  • Set distribution version (DISTRO_VERSION)
  • Set DISTRO_TYPE to release. This is important. It will zap the root password, disable password less root log-in for ssh, disable debugging
  • Start a build
  • Do final testing by QA
  • Make a backup of the buildhost for future reference (point is to be able to restore it...)
  • Sign kernel, uboot, rootfs, Packages files, QA report, OE version of the build (git-tag and push) using FIXME key
  • Upload kernel, uboot, rootfs, feed to FIXME
  • Upload sources used to build the distribution to FIXME
  • Publish instruction and announcement (press...).


Openmoko component/project Release Policy

  • Set the right version number (X.Y.Z)
  • Create a branch projectname-X.Y (if it doesn't exist)
  • Create a tag projectname-X.Y.Z
  • Change version numbers
    • X.Y+1.0 for the main development (or higher)
    • X.Y.Z+1 for the branch
    • Make sure bugtracker gets at least X.Y entry as version
  • Create tarball, create GNU pg signature, upload to standard place (http://downloads.openmoko.org/)
  • Send release notice somewhere