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:
# 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.
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.