Loop/Loop-client Release Process: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Major reformat/relayout to bring it up to date)
 
Line 7: Line 7:
The source files for the standalone are automatically extracted into the [https://github.com/mozilla/loop-client loop-client] repository every hour.
The source files for the standalone are automatically extracted into the [https://github.com/mozilla/loop-client loop-client] repository every hour.


= Release Cycle =
== Automatic updating of loop-client ==
loop-client typically has an approximately four-week release cycle (two weeks dev, two weeks for L10n and release). Current release schedules are tracked on the [[Loop#Cross-Team_Project_Calendar cross-team|calendar]].


Cycle (days are approximate, depending on required timings and other activities:
The master branch of Loop-client is automatically updated from mozilla-central by a script each hour.


* Day 1
The script lives in loop-client repository and is called [https://github.com/mozilla/loop-client/blob/master/extract_from_hg.py extract_from_hg.py].
** Development of loop-client continues in mozilla-central
* Day 14
** A new branch is created for the next release
** Strings are passed to L10n for translation
* Day 28
** L10n strings are imported
** The branch is tagged
* Then (these may happen on different days, depending on availability of QA.
** The branch is released to ops to push to staging
** QA tests staging
** Once verified, ops deploy to production
** QA verifies production


= How to merge latest L10n changesets =
The [[CloudServices/Loop/Deploy#Dev|development server]] runs a cronjob ever hour which runs the script on the loop-client directory on the server (using the mozilla-central hg clone as a base). This also ensures that the development server is automatically updated as well.


This is required for the sections below.
= Release Cycle =
loop-client releases happen when necessary. If strings have changed, there is typically an approximately 2 week cycle to allow them to translate. Current release schedules are tracked on the [[Loop#Cross-Team_Project_Calendar cross-team|calendar]].


* Pull in the latest L10n changes:
== What to Release? ==


  # Update the L10n repository
* If no string changes have occurred since the previous release:
  cd loop-client-l10n
** [[#Releasing loop-client for staging|Release from latest master]].
  git pull origin master
* If string changes have occurred, either:
 
** [[#Start an L10n release|Start an L10n release]] with over a 2 to 3 week cycle
  # Change back to loop-client repo
** or, if there are small bug fixes to ship sooner, create/use branch from previous release and port only the minor changes
  cd ../loop-client
  # Pull across L10n changes
  ./locale-update.py


At this stage, check:
= Automatic updating of loop-client =


# Diffs - to check the changes look sane
The master branch of Loop-client is automatically updated from mozilla-central by a script each hour.
# git status - to check for any added locales (and if so, "git add" them)


  # Commit the L10n changes
The script lives in loop-client repository and is called [https://github.com/mozilla/loop-client/blob/master/extract_from_hg.py extract_from_hg.py].
  git commit -m "Update L10n from changeset <revision>" -a


= Creating a loop-client branch for release to L10n =
The [[CloudServices/Loop/Deploy#Dev|development server]] runs a cronjob ever hour which runs the script on the loop-client directory on the server (using the mozilla-central hg clone as a base). This also ensures that the development server is automatically updated as well.
 
= Start an L10n release =
A new branch is required if there are string changes since the previous release. If there are no string changes, then a branch may be skipped, unless string changes occur during the cycle. If so, a branch should be cut from before any string changes occurs.
 
To create a branch:
 
  git clone git@github.com:mozilla/loop-client.git
  cd loop-client
 
  # Checkout master, or appropriate revision to branch from
  git checkout master
 
  # Create a new branch (replace 0.14 with the main version of the branch)
  git checkout -b 0.14.x
 
  # Push the new branch to the remote
  git push origin 0.14.x


To update L10n
* Ensure CHANGELOG is up to date on latest master.
 
* Next talk to mathjazz in #l10n; confirm that all the strings for Hello are checked in, ready for an L10n release.
* First talk to mathjazz in #l10n; confirm that verbatim has all the strings checked in for Hello.
* Pull the [[#How to merge latest L10n changesets|latest l10n strings into loop-client]]
* Pull the [[#How to merge latest L10n changesets|latest l10n strings into loop-client]]
* Then copy the en-US files to the verbatim directory.
* Then copy the en-US files to the verbatim directory.
Line 89: Line 56:
* Tell mathjazz the push is complete
* Tell mathjazz the push is complete
* mathjazz will then ensure verbatim gets updated.
* mathjazz will then ensure verbatim gets updated.
* Decide on the version number
** Version numbers are generally arbitrary, however, we've so far been following the major.minor.sub version scheme. For releases from the same branch, major and minor stay the same. When a new release occurs with string changes, the minor version gets bumped.
* Create a branch from the latest revision of loop-client's master, i.e. the where the loop.properties for en-US is the same as what was copied to loop-client-l10n.
  git checkout -b 0.14.x
  git push origin 0.14.x
* Send an email to mozilla.dev.l10n, with a '''deadline that is at least 2 weeks in the future, including 2 weekends'''.
** Subject: "Several new strings for Firefox Hello Standalone now in verbatim"
** Body template:
<pre>
Hi All,
We've added a few new strings to the Firefox Hello standalone app. They are in verbatim and pontoon and ready for you to localise.
[Add information about what the strings will relate to]
Deadline: [Insert date]
Updated words: [This can be obtained from verbatim once its synced - look for old previously completed locales, and see what the defect number now is]
Verbatim:
https://localize.mozilla.org/projects/loop/
</pre>
= How to merge latest L10n changesets =
This is required for the sections below.
* Pull in the latest L10n changes:
  # Update the L10n repository
  cd loop-client-l10n
  git pull origin master
 
  # Change back to loop-client repo
  cd ../loop-client
  # Pull across L10n changes
  ./locale-update.py
At this stage, check:
# Diffs - to check the changes look sane
# git status - to check for any added locales (and if so, "git add" them)
  # Commit the L10n changes
  git commit -m "Update L10n from changeset <revision>" -a


= Releasing loop-client for staging =
= Releasing loop-client for staging =
Line 99: Line 114:
To do the actual release:
To do the actual release:


* Decide on the version number
** Version numbers are generally arbitrary, however, we've so far been following the major.minor.sub version scheme. For releases from the same branch, major and minor stay the same. When a new release occurs with string changes, the minor version gets bumped.
* Check out the required changeset or branch
* Check out the required changeset or branch
* Merge [[#How to merge latest L10n changesets|latest L10n changesets]]
* Merge [[#How to merge latest L10n changesets|latest L10n changesets]]
* Update the CHANGELOG file:
* Update the CHANGELOG file:
** Add version and date
** Add bug references
** Add bug references
** Indicate if L10n were updated
** Indicate if L10n were updated
Line 118: Line 136:
   ./create_release.sh <version>
   ./create_release.sh <version>


* Use [https://github.com/rpappalax/deploy-tix deploy-tix] to create a bug for ops to deploy to staging (this is intended to be automated at a later date).
* File a bug, use one of the previous bugs as a template:
 
** https://bugzilla.mozilla.org/buglist.cgi?list_id=12590497&short_desc=loop-client%20stage&resolution=FIXED&query_format=advanced&short_desc_type=allwordssubstr&component=Operations%3A%20Deployment%20Requests&product=Cloud%20Services
  cd ../deploy-tix
** (This will hopefully be automated soon)
  # Build it if you haven't already
  make build
  # Now create the bug (replace username & password with bugzilla credentials)
  ./build/venv/bin/python2.7 deploy_tix -r mozilla -a loop-client -e stage -n 0.16.0 -z -u username -p password
 
* Update the bug with the specifics of any configuration changes if needed.
* Update the bug with the specifics of any configuration changes if needed.
= A note on version numbers =
Version numbers are generally arbitrary, however, we've so far been following the major.minor.sub version scheme. For releases from the same branch, major and minor stay the same. When a new release occurs with string changes, the minor version gets bumped.
= Automatic updating of loop-client =
The master branch of Loop-client is automatically updated from mozilla-central by a script each hour.
The script lives in loop-client repository and is called [https://github.com/mozilla/loop-client/blob/master/extract_from_hg.py extract_from_hg.py].
The [[CloudServices/Loop/Deploy#Dev|development server]] runs a cronjob ever hour which runs the script on the loop-client directory on the server (using the mozilla-central hg clone as a base). This also ensures that the development server is automatically updated as well.


[[Category:Firefox Hello]]
[[Category:Firefox Hello]]

Latest revision as of 10:56, 5 October 2015

Background

Loop-client is the "standalone" part of Firefox Hello. It consists of hosted pages that can be accessed from any browser.

The definitive source files are in mozilla-central, mainly under the standalone directory, however some of the files are shared with desktop.

The source files for the standalone are automatically extracted into the loop-client repository every hour.

Automatic updating of loop-client

The master branch of Loop-client is automatically updated from mozilla-central by a script each hour.

The script lives in loop-client repository and is called extract_from_hg.py.

The development server runs a cronjob ever hour which runs the script on the loop-client directory on the server (using the mozilla-central hg clone as a base). This also ensures that the development server is automatically updated as well.

Release Cycle

loop-client releases happen when necessary. If strings have changed, there is typically an approximately 2 week cycle to allow them to translate. Current release schedules are tracked on the calendar.

What to Release?

  • If no string changes have occurred since the previous release:
  • If string changes have occurred, either:
    • Start an L10n release with over a 2 to 3 week cycle
    • or, if there are small bug fixes to ship sooner, create/use branch from previous release and port only the minor changes

Automatic updating of loop-client

The master branch of Loop-client is automatically updated from mozilla-central by a script each hour.

The script lives in loop-client repository and is called extract_from_hg.py.

The development server runs a cronjob ever hour which runs the script on the loop-client directory on the server (using the mozilla-central hg clone as a base). This also ensures that the development server is automatically updated as well.

Start an L10n release

  • Ensure CHANGELOG is up to date on latest master.
  • Next talk to mathjazz in #l10n; confirm that all the strings for Hello are checked in, ready for an L10n release.
  • Pull the latest l10n strings into loop-client
  • Then copy the en-US files to the verbatim directory.
 # Clone or update as needed
 git clone git@github.com:mozilla/loop-client-l10n.git
 
 # Copy the en-US file (note the change from - to _)
 cp loop-client/content/l10n/en-US/loop.properties loop-client-l10n/l10n/en_US/loop.properties
 
 # Verbatim also needs it in the templates directory
 cp loop-client/content/l10n/en-US/loop.properties loop-client-l10n/l10n/templates/loop.properties
 
 # Now commit and push
 cd loop-client-l10n
 git commit -m "Merge latest en-US strings from loop-client commit <revision>" -a
 git push origin master
  • Tell mathjazz the push is complete
  • mathjazz will then ensure verbatim gets updated.
  • Decide on the version number
    • Version numbers are generally arbitrary, however, we've so far been following the major.minor.sub version scheme. For releases from the same branch, major and minor stay the same. When a new release occurs with string changes, the minor version gets bumped.
  • Create a branch from the latest revision of loop-client's master, i.e. the where the loop.properties for en-US is the same as what was copied to loop-client-l10n.
 git checkout -b 0.14.x
 git push origin 0.14.x
  • Send an email to mozilla.dev.l10n, with a deadline that is at least 2 weeks in the future, including 2 weekends.
    • Subject: "Several new strings for Firefox Hello Standalone now in verbatim"
    • Body template:
Hi All,

We've added a few new strings to the Firefox Hello standalone app. They are in verbatim and pontoon and ready for you to localise.

[Add information about what the strings will relate to]

Deadline: [Insert date]

Updated words: [This can be obtained from verbatim once its synced - look for old previously completed locales, and see what the defect number now is]

Verbatim:
https://localize.mozilla.org/projects/loop/

How to merge latest L10n changesets

This is required for the sections below.

  • Pull in the latest L10n changes:
 # Update the L10n repository
 cd loop-client-l10n
 git pull origin master
 
 # Change back to loop-client repo
 cd ../loop-client
 # Pull across L10n changes
 ./locale-update.py

At this stage, check:

  1. Diffs - to check the changes look sane
  2. git status - to check for any added locales (and if so, "git add" them)
 # Commit the L10n changes
 git commit -m "Update L10n from changeset <revision>" -a

Releasing loop-client for staging

If there's no branch for the current release:

  • Check to see if there were any string changes since the previous release.
  • If there were, cut a branch before the string changes, and if required, merge/port across any additional (non-string) changesets.
  • If not, then the release can be done from master.

To do the actual release:

  • Decide on the version number
    • Version numbers are generally arbitrary, however, we've so far been following the major.minor.sub version scheme. For releases from the same branch, major and minor stay the same. When a new release occurs with string changes, the minor version gets bumped.
  • Check out the required changeset or branch
  • Merge latest L10n changesets
  • Update the CHANGELOG file:
    • Add version and date
    • Add bug references
    • Indicate if L10n were updated
    • Note any configuration option changes/additions
  • Commit the CHANGELOG file
 git commit -m "Update changelog for <version>" CHANGELOG
  • Push the changes
 git push origin <branch>
  • Create the release
 # Replace <version> with whatever the version is, e.g. 0.14.0
 ./create_release.sh <version>