Webtools:Release Notes: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
mNo edit summary
No edit summary
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
These instructions assume you are updating Firefox, the current version is 3.0.1, and the new version is 3.0.2. Substitute as appropriate. In every case and change, '''make sure all pages validate properly'''.
These instructions assume you are updating Firefox, the current version is 3.0.1, and the new version is 3.0.2. Substitute as appropriate. In every case and change, '''make sure all pages validate properly'''.


Note that while this list is specific to Firefox, most of the same things happen for Thunderbird releases.
Note that this list is specific to Firefox, see [[Webtools:Thunderbird_Release_Notes]] for Thunderbird specific information.


Once everything has been tagged for production, the QA contact for the release will file a bug under mozilla.org :: Server Operations: Web Content Push to have the pages pushed live at the appropriate time. Note that the website changes need to be live '''''at least 15-30 minutes prior''''' to Build & Release pushing out update snippets in order to make sure that users do not see 404 errors for pages.
Once everything has been tagged for production, the QA contact for the release will file a bug under mozilla.org :: Server Operations: Web Content Push to have the pages pushed live at the appropriate time. Note that the website changes need to be live '''''at least 15-30 minutes prior''''' to Build & Release pushing out update snippets in order to make sure that users do not see 404 errors for pages.
Line 59: Line 59:


* warn localizers about the imminent release through the mailing list
* warn localizers about the imminent release through the mailing list
* change /xx/l10n/product.php files to update the version number to 2.0.0.x (still used in the old function generating release notes links on the site)
* change /xx/l10n/product.php files to update the product version number to 2.0.0.x (still used in the old function generating release notes links on the site)
* make sure we have the 2.0.0.x number into the php function that generates breadcrumbs (usually I put numbers up to 2.0.0.12 in advance)
* make sure we have the 2.0.0.x number into the php function that generates breadcrumbs if it is more than 2.0.0.20
* add generic php redirects for locale fallback /products/firefox/2.0.0.x/...
* copy mozilla-europe.org/products/firefox/2.0.0.10/* into mozilla-europe.org/products/firefox/2.0.0.11/*
* create /bg/2.0.0.x/releasenotes folder and put the release notes from the previous en-GB version in it (bg is not a public language, we use it to provide diffs to localizers)
* create /bg/2.0.0.x/releasenotes folder and put the release notes from the previous en-GB version in it (bg is not a public language, we use it to provide diffs to localizers)
* get the final en-US release notes and commit the changes to /bg/2.0.0.x/releasenotes/
* get the final en-US release notes and commit the changes to /bg/2.0.0.x/releasenotes/
* check that it looks good on the staging site and that html is still valid
* check that it looks good on the staging site and that html is still valid
* create 2.0.0.x/releasenotes/ folders for all languages with the en-GB release notes in it
* create 2.0.0.x/releasenotes/ folders for all languages with the en-GB release notes in it
* Run `svn propedit svn:externals` in the production local copy and change the product-details external (-r<rev>) to the revision given by mozilla.com webdevs
* Run `svn propedit svn:externals` in the production local copy and change the product-details external (-r<rev>) to the latest revision indicated in http://viewvc.svn.mozilla.org/vc/libs/product-details/?view=log
* commit changes to the production tag and file a Mozilla IT bug to svn up along with mozilla.com changes
* commit changes to the production tag and file a Mozilla IT bug to svn up along with mozilla.com changes
* copy the minor release news item template for all our locales from mozilla europe internal wiki into Dotclear and set it as unpublished, change the news to the new product version number and put the news as "unpublished", put them online when it is officially released.
* copy the minor release news item template for all our locales from mozilla europe internal wiki into Dotclear and set it as unpublished, change the news to the new product version number and put the news as "unpublished", put them online when it is officially released. This should be done ONLY if it is a security release, not a regression fix release like 2.0.0.11
* send the diff of changes from /bg/.../2.0.0.x/releasenotes/ using a link to viewvc.svn.mozilla.org to mozilla europe localizers via the mailing list
* send the diff of changes from /bg/.../2.0.0.x/releasenotes/ using a link to viewvc.svn.mozilla.org to mozilla europe localizers via the mailing list
* if release notes for some locales are translated before the release, tag them for production and inform mozilla IT of the revision numbers involved through the Mozilla IT bug you filed previously to publish your changes
 
==== After the release ====
==== After the release ====
* release is usually around 2AM for Europe, localizers translate the changes in the following days, tag the translation for production as they get done and file individual bugs to have them published by Mozilla IT
* release is usually around 2AM for Europe, localizers translate the changes in the following days, tag the translation for production as they get done and file individual bugs to have them published by Mozilla IT

Latest revision as of 21:27, 18 January 2010

These instructions assume you are updating Firefox, the current version is 3.0.1, and the new version is 3.0.2. Substitute as appropriate. In every case and change, make sure all pages validate properly.

Note that this list is specific to Firefox, see Webtools:Thunderbird_Release_Notes for Thunderbird specific information.

Once everything has been tagged for production, the QA contact for the release will file a bug under mozilla.org :: Server Operations: Web Content Push to have the pages pushed live at the appropriate time. Note that the website changes need to be live at least 15-30 minutes prior to Build & Release pushing out update snippets in order to make sure that users do not see 404 errors for pages.

Beta Release

When putting a new stability/security release version of Firefox on the beta channel prior to final release, there is one bug filed under Websites :: www.mozilla.com:

  • Create in-product pages and add rewrite for Firefox 3.0.2 beta release

Note that no changes to product-details or mozilla-europe.org are made.

Update mozilla.com

  • `svn copy` /en-US/firefox/3.0.1rc to /en-US/firefox/3.0.2rc
  • Replace "Firefox 3.0.1" with "Firefox 3.0.2" in both /en-US/firefox/3.0.2rc/releasenotes/index.html and /en-US/firefox/3.0.2rc/whatsnew/index.html (there are at least four places to change)
  • Update the release date in /en-US/firefox/3.0.2rc/releasenotes/index.html (make sure to correctly specify if this is RC1, RC2, etc.)
  • Edit .htaccess, uncomment the "Temporary rewrite" RewriteRule for Firefox betas, and change the two places that refer to 3.0.1 to 3.0.2 (3\.0\.1 and 3.0.1)
  • Have QA look at the staging site with your changes
  • Once QA is happy, merge to production
  • Once tagged for production, comment out the RewriteRule in the trunk version of .htaccess and commit

Final Release

When releasing a new version of a product, there are two bugs that are filed under Websites :: www.mozilla.com:

  • Create in-product pages for Firefox 3.0.2 release
  • Copy localized in-product pages for Firefox 3.0.2 release
    • pascalc does this usually, so you just need to tag his changes

Update product-details

  • Follow the directions in the top of the class
    • When you commit this change, make note of the revision
  • Note that you should check the shipped-locales file to make sure no locales were added/removed for this release
    • If something needs to be changed, update product-details appropriately

Update mozilla.com

  • `svn copy` /en-US/firefox/3.0.1 to /en-US/firefox/3.0.2
  • Edit /en-US/firefox/3.0.2/releasenotes/index.html to have correct information for this release (change version number, update links, update release date, update known issues, remove Solaris builds section for now, etc.)
  • Add release to /en-US/firefox/releases/index.html
  • Run `svn propedit svn:externals` in / and change the product-details external (-r<rev>) to whatever revision you just committed
  • Make sure pascalc has copied all the localized in-product pages and updated their versions properly for this release
  • Have QA look at the staging site with your changes
  • Once QA is happy, merge to production (don't forget the .htaccess revert and the localized in-product pages!)
  • Notify (irc works):
    • mozilla-europe
    • mozilla-japan
    • mozilla china (?)

Update mozilla-europe.org

This applies to both Thunderbird and Firefox except for the news item

Before the release:

  • warn localizers about the imminent release through the mailing list
  • change /xx/l10n/product.php files to update the product version number to 2.0.0.x (still used in the old function generating release notes links on the site)
  • make sure we have the 2.0.0.x number into the php function that generates breadcrumbs if it is more than 2.0.0.20
  • copy mozilla-europe.org/products/firefox/2.0.0.10/* into mozilla-europe.org/products/firefox/2.0.0.11/*
  • create /bg/2.0.0.x/releasenotes folder and put the release notes from the previous en-GB version in it (bg is not a public language, we use it to provide diffs to localizers)
  • get the final en-US release notes and commit the changes to /bg/2.0.0.x/releasenotes/
  • check that it looks good on the staging site and that html is still valid
  • create 2.0.0.x/releasenotes/ folders for all languages with the en-GB release notes in it
  • Run `svn propedit svn:externals` in the production local copy and change the product-details external (-r<rev>) to the latest revision indicated in http://viewvc.svn.mozilla.org/vc/libs/product-details/?view=log
  • commit changes to the production tag and file a Mozilla IT bug to svn up along with mozilla.com changes
  • copy the minor release news item template for all our locales from mozilla europe internal wiki into Dotclear and set it as unpublished, change the news to the new product version number and put the news as "unpublished", put them online when it is officially released. This should be done ONLY if it is a security release, not a regression fix release like 2.0.0.11
  • send the diff of changes from /bg/.../2.0.0.x/releasenotes/ using a link to viewvc.svn.mozilla.org to mozilla europe localizers via the mailing list
  • if release notes for some locales are translated before the release, tag them for production and inform mozilla IT of the revision numbers involved through the Mozilla IT bug you filed previously to publish your changes

After the release

  • release is usually around 2AM for Europe, localizers translate the changes in the following days, tag the translation for production as they get done and file individual bugs to have them published by Mozilla IT