This article is only intended as a reference for community members involved in releasing. End-users do not need to perform any of the steps outlined in here.

Ensure that:

• A changelog is lying within the firstrun server, and note down its url
• You have a complete build lying within our build system
• The build is working correctly, do some tests. It would be sad to have to bundle again if something is wrong within the build.
• You have the MAR tool for your platform installed, and downloaded the make_full_update.sh and common.sh scripts. Insert a line into the end of the make_full_update.sh script:

# Append remove instructions for any dead files.
append_remove_instructions "$targetdir" >> $manifest

# ---- THIS IS THE LINE TO ADD:
read -p "Press [Enter] to continue..."

$BZIP2 -z9 "$manifest" && mv -f "$manifest.bz2" "$manifest"

eval "$MAR -C \"$workdir\" -c output.mar $targetfiles"
mv -f "$workdir/output.mar" "$archive"

# cleanup
rm -fr "$workdir"

With a build shell, enter the build system and execute:

cd compiled/
/path/to/scripts/make_full_update.sh update.mar dist

alternative for Linux/Mac: (to be completed)

cd compiled/update
make complete

When prompted to press enter we can make some manual adjustments to the files lying in dist.working, which will then be bundled. We're interested in the update.manifest file. At least on windows, the script generates add-if lines for the files within the extension folder. As we want to install new bundled add-ons as well, change these lines to just add the extension files.

After this change, hit enter in the build console, and the package is now generated as update.mar within the compiled folder. Upload this file with a suitable name to somewhere (but not sourceforge as they suck way to much to be compatible to our updater), and write down its download url. Maybe adding multiple github tags is a good idea…

Calculate a SHA1-checksum of the mar file, and write down its size. Write an xml file with the content (adjust the stuff in <> brackets):

<?xml version="1.0"?>
<updates>
  <update type="major"
          version="<VERSION OF THE BUNDLE>"
          extensionVersion="<VERSION OF THE BUNDLE>"
          buildID="<BUILD ID OF THE BUNDLE>"
          licenseURL="http://www.gnu.org/licenses/gpl-3.0-standalone.html"
          detailsURL="http://firstrun.getnightingale.com/release-notes/<VERSION TO UPGRADE TO>">
    <patch type="complete"
           URL="<URL TO THE MAR FILE>"
           hashFunction="SHA1"
           hashValue="<SHA1-HASH OF THE MAR FILE>"
           size="<SIZE OF THE MAR FILE, IN BYTES>"/>
  </update>
</updates>

Save that file with the name for the operating system you're building updates for, for example: WINNT_x86-msvc-default-update.xml

For testing purposes, append a suffix -testing to the file name and upload it to googlecode. Example: WINNT_x86-msvc-default-update-testing.xml

Now, open an old version of Nightingale, go to about:config and add a new config field app.update.url.override with the string value https:///github.com/nightingale-media-player/nightingale-hacking/releases/download/nightingale-%VERSION%/%BUILD_TARGET%-%CHANNEL%-update-testing.xml. If the update is vaid, you can then search for updates, and initiate the update process. Be sure to check if the updated version works as expected!

ATTENTION: This step will cause all Nightingale installations of the target version to be able to fetch the update. Do this only on the time of release, and NOT as release preparation.

In gitHub, choose “Edit Release” on the version you're updating from. Delete the empty dummy update xml file for the platform of your update, then hit update release. Then click “Edit Release” again, upload the correctly named xml file and hit update release one last time.

It is highly recommended to only push the update after the release branch for the NEW release has been created on gitHub, with dummy xml files preventing nasty 404 errors when newly updated installations search for updates. Dummy files do not contain actual updates, they only prevent the 404 error to be visible when manually checking for updates.

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/XULRunner/Application_Update

Updates can possibly be built much simpler, however it is not verified that these mars actually are ususable. After building just run

make -C compiled/update complete

This will generate a mar plus description file (with all the checksums etc.) in compiled/_built_installer.