Building and Releasing Personas

Development Build

Building and releasing a development build of Personas is easy.

First, clone the repository:

hg clone http://hg.mozilla.org/labs/personas/ personas

Then build the extension, package it up, and push the package to the distribution server:

cd personas/client/
make clean && make build channel=dev && make package channel=dev && make publish

Note: you need an account on the staging server (stage.mozilla.org) for the distribution server (ftp.mozilla.org) with access to the distribution directory (/pub/mozilla.org/labs/personas/) in order to do this.

Users who are using an older development build will be automatically updated to the new build the next time Firefox checks for updates.

Stable Release Build

Building and releasing a stable release build of Personas is a bit more involved. The following procedure uses the example of building and releasing version 1.3.1, a minor update to version 1.3, off the client-1.3 branch.

Clone the repository:

hg clone http://hg.mozilla.org/labs/personas/ personas

Update your working copy to the release branch:

cd personas/
hg update -r client-1.3

Make sure the version string in client/client.mk represents the version you are releasing (in this case "1.3.1"). If it doesn't, change it, then commit your change:

(edit client/client.mk)
hg commit -m"update version for next release"

Make sure the max version strings in client/client.mk represent the max versions of Firefox and Thunderbird with which the extension is compatible and which AMO allows you to specify. If they don't, change them, then commit your change:

(edit client/client.mk)
hg commit -m"update max versions with which extension is compatible"

Make sure strings that are missing in localizations have been replaced by their English equivalents.

You can do this either manually or by downloading a localization bundle from Babelzilla that has automatically replaced missing strings, but make sure to only apply the appropriate changes in the bundle, as Babelzilla localization bundles sometimes contain localizations that should not be incorporated into Personas (f.e. abandoned ones), and they can contain an en-US "localization" from which comments have been stripped.

Also, you should only ever do this on a string-frozen branch, and never on the trunk, since otherwise, the next time you uploaded Personas to Babelzilla, it would look like those strings have already been localized, so they wouldn't get localized.

(replace missing strings with their English equivalents)
hg commit -m"replace missing strings with their English equivalents"

Make a release build:

cd client/
make clean && make build channel=rel && make package channel=rel

You should now have a package called personas-1.3.1.xpi in the client/ directory. Before becoming a final release, it needs to be made available as a release candidate for testing purposes. So rename the file to reflect its status as a release candidate:

mv personas-1.3.1.xpi personas-1.3.1rc1.xpi

Push it to the distribution server:

mkdir -p dist
mv personas-1.3.1rc1.xpi dist/
make publish

Tag the repository with a tag identifying the revision you released as a release candidate:

hg tag client-release-1.3.1rc1

Note: release tags should follow the format client-release-(version).

Note: although the filename and tag contain a string identifying the release candidate ("rc1"), the version of the extension, as specified in client/client.mk, should not include this string, so you can release the build (once vetted) as the final release without having to change it.

Publicize the build. Have QA and adventurous users test it.

If release blockers are found in the candidate, repeat this procedure to create another release candidate, incrementing the number of the release candidate in the filename and the tag. Do this as many times as needed until all release blockers are fixed.

Once you have a release candidate with no blocker bugs, upload it to AMO and publicize the release.

Then tag the repository with a release tag identifying the revision you released as the final release:

hg tag client-release-1.3.1

Update the version string in client/client.mk to reflect the next anticipated release off the given branch (f.e. "1.3.2"), then commit your change:

hg commit -m"update version for next anticipated release"

Push your changes back to the central repository:

hg push ssh://hg.mozilla.org/labs/personas/

Branching for a Stable Release

Before building and releasing a stable release from the trunk, you should create a branch to isolate changes that you make for the release (and subsequent minor update releases) from ongoing development. The following procedure uses the example of creating the client-1.4 branch for the 1.4 stable release:

Clone the repository:

hg clone http://hg.mozilla.org/labs/personas/ personas

Create the branch (which also updates your working copy to that branch), and commit the "change":

hg branch client-1.4
hg commit -m"create stable release branch for next release"

Note: branch names should follow the format client-(version).

Change back to the trunk:

hg update -r default

Update the version string in client/client.mk to reflect the next anticipated release off the trunk (f.e. "1.5"), then commit your change:

hg commit -m"update version for next anticipated release"

Mercurial will tell you that it created a new head. That's as it should be.

Push your changes back to the central repository:

hg push -f ssh://hg.mozilla.org/labs/personas/

You have to use the -f option to force the push because you are creating a new remote head, and Mercurial won't do that by default.

Finally, publicize the branch so developers know about it, since Mercurial will warn them about the new head when they next pull from the central repository.

Merging Changes to a Stable Branch

After creating a stable branch, you may find there are changes on the trunk that you would like to take on the branch, either because they are fixes for regressions in a release candidate or because they are candidates for a minor update to a stable release (i.e. a 1.3.1 update to 1.3).

To merge those changes to the branch, clone the repository:

hg clone http://hg.mozilla.org/labs/personas/ personas

Update your working copy to the stable branch (in this example, the client-1.3 branch):

cd personas/
hg update -r client-1.3

Export the change from the trunk (in this example, revision 3c92b1b9f9b2), import it into your working copy, and commit it to the branch in one fell swoop:

hg export 3c92b1b9f9b2 | hg import -

This works because even though your working copy is updated to the branch, it has access to the trunk's revisions. And when you import patches that have been exported from a Mercurial repository, Mercurial preserves the user, date, and summary from the original checkin when it automatically commits them.

Note: in Don't repeat yourself: merging across branches, the Mercurial documentation suggests a technique for merging across branches that assumes you are merging across branches in separate repositories (whereas Personas uses named branches within a single repository), that you initially commit the fix to the stable branch (whereas Mozilla developers almost always commit the fix to the trunk first), and that you are merging all changes (whereas Personas developers usually merge only selected changes), so it's probably not appropriate for Personas.

Localization

Personas is localized via Babelzilla. When you make changes to text that appears in the user interface of the extension, you have to upload Personas to Babelzilla in order for its localizers to localize that text. In order to do that, you need to have access to the account currently authorized to upload Personas to Babelzilla.

In general, don't upload Personas to Babelzilla after every change. Instead, do so once, at the end of a development cycle, but at least a week before you plan to build a release candidate for the release, to give localizers enough time to update their localizations without making them repeatedly deal with localization requests.

After uploading Personas to Babelzilla, update the extension whenever a localizer updates their localization. In addition to incorporating their changes, make sure the list of localizers in client/install.rdf reflects the current localizers for the extension, so the appropriate people get credit for their work.

When incorporating a new localization, make sure to update client/chrome.manifest to include that localization in the list of localizations provided with the extension.