Releases:Website Checklist

From Camino Wiki
Jump to navigation Jump to search

Major release

There's no clear path to doing a major release yet, however I want to keep track of a few things here for future reference.

  • Line up some blog coverage and start writing a press release about 2 weeks out.
  • Contact host (Network Redux) two to three days before release so they know load will be high.
  • Before starting to make changes to the website:
  1. Archive the existing stage, in case there's something there that you need later:
    cd /www
BZIP2=-9 tar -jcf /home/cbo/stage-pre-2.1.tar.bz2 cbo-www-stage
    (Make sure you are not inside stage when performing this command)
  2. rsync the contents of the live website over to stage:
    cd /www
rsync -a cbo-www/ cbo-www-stage --delete
    Be extremely careful when issuing this command, as it will delete things! In particular, note the source directory has a trailing slash and the target directory does not.
  • Go through documentation changes and make them as needed. Be sure to read over all pages in /documentation/, since there will be changes to things you've forgotten are in certain sections. Make sure to update the TOC links.
    • Verify that all the search plug-ins still work, still have site icons, and that sites haven't added/removed their own plug-ins.
  • Update the main page screenshot and CSS feature call-out
  • /features/ - Update for new features
  • /releases/ - Copy the folder for the previous major release (e.g., 1.5 for the 1.6 release) in /releases/
    Find/replace 1.5 with 1.6, and 1.0 with 1.5
    Update the release date in the box
    Update the ML languages
    Note that getting these pages from the wiki into Coda (and into decent HTML) requires some manipulation
    Be sure to preserve any class or id attributes from the previous version when pasting in the new information.
    • Update the /releases/ page for the previous version (e.g., 1.6.10 for the 2.0 release) using the steps from #Major minor release
      If the new version drops support for a Mac OS X major version, copy the text from 1.0.6 to the page for last version of the old version and adapt for the current state (see text samples from #Major minor release)
  • /press/
    • Add new screenshots
    • Add the new press release
  • /legal/
    • Update version number regarding licence applicability
    • Check the privacy policy and "Know Your Rights" document for needed updates (e.g., new features with privacy implications); compare to the comprable fx documents
  • /downloads/
    • Do the Download, Downloads Old, and Download Releases steps from the #Major minor release information
    • Make downloads/releases/nightly/ point to the "latest-" folder for the active development branch
  • /contribute/
    • Hide the "Preview" box
  • /preview/
    • Update the title and "body" to the "index-released" version of the page (watch the date and js)
  • /js/ - ua-detection
    • versions.js
      • Set the latestRelease to 2.0
      • Set the latestPreRelease and associated variables to 2.1a1
      • Add the last beta to oldPreRelease
      • Update the minimum OS in latestReleaseOS if necessary
      • If the new release drops OS support
        • Remove prior releases from 'oldRelease' (this may clear the entire 'oldRelease' array)
        • Add new one6Release and one6xReleases variables, filled with the appropriate versions
    • ua-messages-*
      • If you had multiple release candidates, update the 'if' logic to handle those versions appropriately (see Bug 699335 comment 11 for an overview)
      • Comment out the active messageOldPreRelease and un-comment the other
      • If the new release drops OS support:
        • Add one6Release and one6xReleases messages, and update the versions/OS versions
        • Add 'if statements' for new one6Release and one6xReleases near the bottom
        • In the period before 1.6.10 is declared EOL, remove the "not supported" sentence from 'messageOne6Release'
        • When 10.4 support is being dropped, rewrite the JS to parse OS version, and send different messages to 10.4 2.x users and 10.5± 2.x users
    • Watch out for typos!
  • System requirements boxes
    • On home and /features/, update the system requirements and version number
  • Other
    • Double-check that you've done everything required from Major minor release (htaccess, header, blog, update)
  • Staging the release
    For the most part, follow the Major minor release
    • QA the RC and the ML build
    • Get the builds in bouncer
    • Stage the software update definition and update descriptions for each language
    • disable/redirect the preview site to the main page
  • To push the new site live:
  1. Archive the existing site, in case there's something there that you need later, or you make a mistake:
    cd /www
BZIP2=-9 tar -jcf /home/cbo/cbo-pre-2.1.tar.bz2 cbo-www
    (Make sure you are not inside cbo-www when performing this command)
  2. rsync the contents of the updated stage website over to the live website:
    cd /www
rsync -a cbo-www-stage/ cbo-www --delete
    Be extremely careful when issuing this command, as it will delete things! In particular, note the source directory has a trailing slash and the target directory does not.

Milestone release

There's no clear path to doing a milestone (alpha/beta) release yet, however I want to keep track of a few things here for future reference.

  • Add/re-enable the right messageOldPreRelease in ua-messages{-start).js and update latestPreRelease, latestPreReleaseText, and latestPreReleaseType (see relevant section in Major minor release below; only needed when switching into or out of a time when a preview release is available)
  • Add the new version number and name to versions.js
  • Update
  • Blog (see relevant section in Major minor release below)
  • preview.cbo
    • Be sure to fix the "latest stable version" link/text
  • cbo/contribute (unhide the Preview box and/or update the version number)
  • Software update (see relevant section in Major minor release below)
  • Lock down wiki release notes
  • Update the forum, tag, and roadmap as described ing Major minor release's final items section

Major minor release

When releasing a Camino 1.5.x/1.6.x release, the following things need to be done to prepare the website and to update it:

In Coda

  1. Update any files you might be touching before starting
  2. Relnotes (/releases/)
    1. Duplicate releases/1.5.3/
    2. Rename it to releases/1.5.4/
    3. Change page title at the top
    4. Change intro to say 1.5.4. (and 1.5.3 instead of 1.5.2)
      • For M.m->M.m.x, replace intro ("After over a year of hard work") with "Camino 2.0.1 is a stability and security update for Camino 2.0. All users are urged to upgrade.") and add "notes_changes" and "notes_about" sections (see any previous M.m.x page)
      • For M.m.1->M.m.2, change "update for Camino 1.6" to "update for Camino 1.6.x"
    5. Copy/Paste notes from wiki page and format like previous notes
      • Update any Known Issues changes
    6. At bottom of document, change download links (en and ML) to point to 1.5.4
    7. Change release date
    8. Add any languages (none this release)
    9. Copy the intro 'p' ("no longer latest release") from 1.5.2 to 1.5.3 and s/1.5.2/1.5.3
      • For M.m->M.m.x, prepend this into 'p' before the "After over a year of hard work" 'p'
      • For EOL-OS releases, copy the format from 0.8.5/1.0.6 and point to /releases/latest/ until that branch becomes EOL as well (then point to the final release on the newly-EOLed branch).
        • active, not yet EOL:
          <p>Camino 1.6.10 is a stability and security update for Camino 1.6.x. All users on Mac OS X 10.3.9 are urged to upgrade; all users of Mac OS X 10.4 or higher should upgrade to <a href="/releases/latest/">the latest Camino 2 release</a> instead.</p>
        • EOLed:
          <p>Camino 1.6.11 is a security and stability update for Camino 1.6.x users running Mac OS X 10.3.9. Camino 1.6.11 will be the last update in the 1.6.x series and is thus the last version of Camino to support Mac OS X 10.3.</p> <p>All users on Mac OS X 10.3.9 are urged to upgrade to this version; all users on Mac OS X 10.4 or higher should upgrade to <a href="/releases/latest/">the latest Camino 2 release</a> instead.</p>
    10. If this is a release on a branch that was superseded by an EOL-OS release, fix the mentions of "Users of $OLDOS should use Camino X.n.z instead" to point to this new release (e.g., when releasing 1.6.11 after 2.0 is out, update 2.0 and 2.0.1 to point to 1.6.11 instead of 1.6.10)
  3. Download
    1. Duplicate /download/releases/1.5.3/
    2. Rename it to /download/releases/1.5.4/
    3. Duplicate /download/releases/1.5.3-MultiLang/
    4. Rename it to /download/releases/1.5.4-MultiLang/
    5. Change page title and URL at top of both pages to be 1.5.4
    6. Change intro text to be 1.5.4 on both pages (including download URLs) and the legal line
    7. Change relnotes links (en, ML) near the bottom on both pages
    8. Change release date on both pages
    9. Add any languages (none this release) on the MultiLang page
  4. Downloads Old (1.5.3 + MultiLang)
    1. Change title to "Download" (remove 'ing' and '…')
    2. Remove the two $download* variables at the top of the old (1.5.3) page.
    3. Copy/paste "intro" and "col2span" from a previous release and ML release (this removes the graphical instructions)
    4. s/1.5.2/1.5.3 (3x per page)
  5. Download Releases
    1. Edit /download/index.php
    2. Edit the version numbers in the download button URLs
    3. Add any new languages to the description for the ML button
    4. In the "Latest Release" section, s/1.5.3/1.5.4
    5. Copy/Paste the previous release line and s/1.5.2/1.5.3
    6. Add any languages (Polish this release)
    7. If this is a release on a branch that was superseded by an EOL-OS release, fix the mentions of "Camino X.n.z is the last release of Camino for users of $OLDOS" to point to this new release (anchor, version text). (E.g., when releasing 1.6.11 after 2.0 is out, update the page to point to 1.6.11 instead of 1.6.10)
  6. htaccess
    1. Change this line: RewriteRule ^releases/latest/?$ /releases/1.5.3/ [R=302]
  7. JS version variables/Home/Start Page messages (versions.js, ua-messages.js and ua-messages-start.js)
    1. Change latestRelease to 1.6.1 in versions.js
    2. Add the last release to the front of oldRelease array in versions.js
    3. For Camino 2.1.1, remove the hacks in ua-messages*.js that treated 2.1 RC1 and RC2 as different from RC3/2.1 final.
    4. For new major releases, comment out the active messageOldPreRelease and un-comment the other
    5. For alphabeta releases:
      • increment the latestPreRelease, latestPreReleaseText, and latestPreReleaseType, and oldPreRelease array (if needed) in versions.js
      • Choose the correct messageOldPreRelease; uncomment the one linking to preview.cbo and comment out the other one
  8. preview.caminobrowser.org
    1. If the preview site is active, fix the "latest stable version" text.
  9. Blog
    1. Remove the oldest blog post on the main blog page
    2. Copy the 1.5.3 blog post and paste at the top of the page
    3. Fix any wording and version numbers throughout the post (h2 id, h2 text, p text, p links, and bottom p text and links)
    4. Update any languages added in this release (currently we just do this in the list)
    5. Fix date and time (and PST/PDT)
    6. Note the texts are different for 1) major releases, 2) milestones, and EOL releases on branches which are the last to support an OS (for the latter, see [1] and [2]).
    7. Copy and paste it into /blog/2007/ or /blog/2008/, creating it if necessary
      • If you add a new year, be sure to
        • Add the Archives link to the sidebar on all /blog/ pages
        • Fix the year in the php $pagetitle
    8. In atom.xml:
      1. Remove the oldest entry in the file
      2. Copy/Paste the most recent blog post to the top of the feed
      3. Fix the date
        1. Issued is in local time Pacific (-700 PDT/-800 PST)
        2. Created and Modified are in Z time [3]
      4. Fix the 'link' to go to the correct post and have the correct title
        1. Make sure that the year in the link is correct when copying from an old year
      5. Up the 'id' incrementally by 1
      6. Fix the 'title'
      7. Remove everything in the 'content->div' tag
      8. Paste the blog post HTML into the 'content->div' tag
      9. Fix links in the post to be absolute, not relative
      10. Fix the Modified of the entire feed near the top of the file (in Z time too!)
    9. (Note: If you need to change the post after this point, be sure to change the post in all three files and the <modified> of both the feed itself and of the entry.)
  10. Update
    1. Duplicate the M.m.x update description files
      N.B. Major releases and milestone releases have different description formats (intro pgh of their relnotes, plus link to preview.cb.o)
    2. In each description file:
      1. Change the current version number at the beginning of the sentence to the current version
      2. If M.m.2, change "stability update for Camino 1.6" to "1.6.x"
      3. Change the version number in the relnotes link
      Update Description Renamer will handle these steps for you automatically for point releases, except for the "If M.m.2"
    3. Duplicate the M.m.x update definition files for en-only and ML
    4. In each definition file:
      1. Update every value (in most cases, MinOSVersion, Arch, and Intl will not change, but every other one will need updating)
      2. smorgan will generate the signature (pink and mento also have the key)
    5. If there is an active additional update (“fake update”)
      1. Update the additional update’s definition to match the new values in the new definition (keeping MinCaminoVersion, MaxCaminoVersion, and DescriptionBase)
      2. Update the version number in the additional update’s description file(s) to match the version number in the new description files.
      See bug 574149 comment 5 and comment 6 for more info about “fake updates” and their requirements.

Final items (not in Coda)

  1. Get release version into Bouncer (pending final release file; usually you can—and need to—do this at least the day before, and typically ardissone or mento files the bug when the bits are hot off the builder for plenty of lead time)
  2. Get the release into Breakpad
  3. File a bug (or poke a Bugzilla admin) to hide the release's flag and add a new flag for the next release.
  4. Try to get mozillaZine to update their links :P
  5. Email mozilla-news-submissions@mozilla.org about release so we end up in newsletter.
  6. Fix the /topic in #camino
  7. caminobrowser should twitter
  8. New post at the Forum
    1. Unsticky the RC thread
    2. Find the thread for the previous release, copy it with s/oldversionnumber/newversionnumber/, and post as a new sticky thread
      Releases:Website_Checklist:Forum_Texts
  9. Update the tag in Development:Building:FAQ
  10. Update the dates and links in Development:Roadmap
Retrieved from "http://wiki.caminobrowser.org/index.php?title=Releases:Website_Checklist&oldid=12096"