Loop/Loop-client Release Process: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(New section to simplify descriptions of how to merge l10n changesets)
(Major reformat/relayout to bring it up to date)
 
(2 intermediate revisions by the same user not shown)
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:
* 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.
  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
 
* 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>


* File a bug for ops to create the staging release (this may be automated soon).
* File a bug, use one of the previous bugs as a template:
** Use [https://bugzilla.mozilla.org/show_bug.cgi?id=1135053 this bug] 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
 
** (This will hopefully be automated soon)
= A note on version numbers =
* Update the bug with the specifics of any configuration changes if needed.
 
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>