DOM Inspector/Releases/Checklist

From MozillaWiki
Jump to: navigation, search

This is a snapshot of the page, documenting a future process. Some things will not work with the current state of the DOM Inspector repository.

DOM Inspector releases are prepared from a release branch. Get there by doing updating to the branch point of the latest branch, then updating the working directory to the tip of the branch:

 $ hg update DOMI_LATEST_BRANCH && hg update

DOM Inspector release day

From the release branch, the release process is as follows:

  • Verify that the maxVersion strings in install.rdf on the release branch for all applications match the versions that correspond to the current nightlies derived from mozilla-central. (This shouldn't be necessary if you've already done everything you're supposed to do on the last merge day.)
  • Change the makefile to reflect the new version number. Use the tracking bug for that release in your commit.
    • e.g., when releasing DOMi 2.0.12, you would change it from 2.0.12pre to 2.0.12 on the DOMI_2_0_12 branch. The commit message would be "Bug 738048 - (DOMi2.0.12) DOM Inspector 2.0.12". See changeset c42fd9baba56.
  • Add a version-specific tag and a DOMI_LATEST_RELEASE tag
    • e.g.,
      $ hg tag DOMI_2_0_12_RELEASE
      $ hg tag -r DOMI_2_0_12_RELEASE DOMI_LATEST_RELEASE
  • Build it
    • Download the latest mozilla-central release source drop
      • e.g., get it from ftp://ftp.mozilla.org/pub/firefox/releases/latest/source
      • This should work with other, non-Firefox mozilla-central project source drops since we're not actually going to build the application; we're just going to leverage the mozilla build system. It's just that the Firefox ftp directory includes a "latest" symlink, and others don't.
    • Extract the source drop
      • e.g.,
        :~/src$ tar xjf ./firefox-12.0.source.tar.bz2</samp>
    • Drop dom-inspector into the extensions directory
      • Clone the repo there:
        :~/src/mozilla-release$ hg clone http://hg.mozilla.org/dom-inspector ./extensions/inspector
      • Update to the release branch:
        :~/src/mozilla-release$ hg update -R ./extensions/inspector DOMI_LATEST_RELEASE
      • Alternatively, you can mv/cp/hg archive the repository you were working from before, but I usually clone a new one for good measure, since the dom-inspector repo is so small.
    • Edit the .mozconfig to enable DOM Inspector in the build (and nothing else):
      ac_add_options --enable-application=extensions
      ac_add_options --enable-extensions=inspector
    • Start the build:
      :~/src/mozilla-release$ make -f ./client.mk
    • Fish out the XPI from $MOZOBJDIR/dist/xpi-stage
      • e.g., ~/src/mozilla-release/objdir-i686-pc-linux-gnu/dist/xpi-stage/inspector-2.0.12.xpi
  • Prepare the release notes
    • find the dependent bugs for release bug
    • The notes take this form:
      <ul>
        <li>
          <a href="URL"
             title="Bug bug id - bug summary">Bug bug id</a>&nbsp;- bug summary (patch by contributor)
        </li>
      </ul>

      Localization fixes:
      <ul>
        <li>Language: Contributor</li>
      </ul>
    • feel free to add explanatory text or additional prose above or below the notes
  • Submit it to AMO
    • Paste the release notes
    • Ping someone in #addons for review
  • Leave a comment in the release bug about the AMO status
  • RESOLVE the bug when it gets reviewed and is made available on AMO

DOM Inspector branch days

From the default branch, the branch process is as follows:

  • Verify that the maxVersion strings in install.rdf on the release branch for all applications match the versions that correspond to the current nightlies derived from mozilla-central. (This shouldn't be necessary if you've already done everything you're supposed to do on the last merge day.)
  • Verify that any translations updated on the last release branch have been copied over to the default branch.
  • Remove the DOMI_LATEST_BRANCH tag from the last branch
    $ hg tag --remove DOMI_LATEST_BRANCH
  • Branch, and use the tracking bug that corresponds to the new branch for your commit.
    • e.g., if the last version of DOM Inspector released was 2.0.11, the current version on the default branch should already be 2.0.12pre, and the name for the new branch will be DOMI_2_0_12.
      $ hg branch DOMI_2_0_12
    • The commit message would be "Bug 738048 - (DOMi2.0.12) DOM Inspector 2.0.12 (branch for localization)". Make sure you make your commit now, because tagging in the next step will steal the opportunity.
  • Tag the new branch DOMI_LATEST_BRANCH
    $ hg tag DOMI_LATEST_BRANCH
  • Switch back to the default branch
    $ hg update default
  • Create a new tracking bug for the version of DOM Inspector that follows the version for the newly-created branch. Give it an alias and a summary that correspond to the version that it tracks, and make it depend on the tracking bug for the new branch (which should already exist).
    • e.g., if the name of the newly-created branch was DOMI_2_0_12, create a bug with the summary "DOM Inspector 2.0.13", and give it the alias "DOMi2.0.13". Make it depend on bug DOMi2.0.12.
  • Change the makefile on the default branch to reflect the new version number. Use the new tracking bug for your commit.
    • e.g., if you just branched DOMI_2_0_12 and created a tracking bug for DOM Inspector 2.0.13, you would change the makefile from 2.0.12pre to 2.0.13pre on the default branch. The commit message would be "Bug 748542 - (DOMi2.0.13) DOM Inspector 2.0.13 (bump version number to 2.0.13pre)". See changeset af3dd47abfe5.
  • Leave a comment in the tracking bug corresponding to the version that just branched.
    • e.g., if the newly-created branch is DOMI_2_0_12, you would leave a comment in bug 738048.
  • Attempt to notify translators who are involved with out-of-date localizations that the repo has branched so that localizers have a stationary target for the next six weeks.