Firmware Release Process

Brett Walach edited this page Oct 7, 2016 · 1 revision

As of 10/7/2016 this process is out of date. There are many more tests that take place before each release, and other files that need updating. TODO: update this process.

Testing

  • build TEST=wiring/api and verify the build succeeds. (No need to flash this to a device.)
  • build TEST=wiring/no_fixture, flash to a Core, Photon and Electron (U260 and G350) and verify all tests pass. Connect serial, press 't' to start tests. (When building on the core, clean all COMPILE_LTO=y is needed for the code to fit into available flash.)
  • build TEST=wiring/networking, flash to a Core, Photon and Electron (U260 and G350) and verify.

Release Checklist

  • create a new release branch release/vX.Y.Z or release/vX.Y.Z-rc.n (if pre-release), based on develop and check out that branch.
    • Note that once a branch is pushed to staging, then production, it should not be updated directly or else production will be affected. Instead a new branch should be checked out and the release process should be followed for staging and production again.
  • Bump module versions in preparation for the release. The versions are deliberately not bumped until the actual release so that users who were building from source will also get the updated release when it is available in the cloud. In firmware/modules/shared/system_module_version.mk
    • bump SYSTEM_PART1_MODULE_VERSION
    • bump SYSTEM_PART2_MODULE_VERSION
    • bump USER_PART_MODULE_VERSION if the interface to user apps changes.
  • update firmware/system/system-versions.md
  • check system/inc/system_version.h making sure SYSTEM_VERSION reflects the next version and proper defines are included. Proper defines include #define SYSTEM_VERSION_v060RC1 0x00060001 for SYSTEM_VERSION and #define SYSTEM_VERSION_060RC1 for Library/App creators.
  • check build/version.mk, making sure VERSION= and VERSION_STRING= are set to the correct version
  • update build/release.sh, adding new VERSION="0.5.0-rc.1" targets
  • perform a clean build of the modules directory:
cd modules
make PLATFORM=photon clean all
  • run build/make_release.sh to create ALL system firmware binaries
    • binaries are available in build/releases
  • add docs to a feature branch in the docs repo
  • update CHANGELOG.md in firmware repo, add links to issues and/or documentation for each change
  • Add tags for this release candidate in the format vX.Y.Z-rc.N, e.g. v0.5.0-rc.1 for the 1st push to staging git tag v0.5.0-rc.1
    • When pushing this tag, make sure to push explicitly to prevent potentially old/deleted/rebased tags from being pushed: git push origin v0.5.0-rc.1
  • ask Dave/Wojtek to add to compile service on staging
  • perform OTA update on staging against the new release. Verify system firmware version using 'v' over serial.
  • ask compile server team to configure compile server on prod (Try not to do this on a Friday)
  • create github release for the tag
    • copy changelog notes
    • previous release steps.
    • upload built system firmware images
  • inform CLI team of new system firmware images so they can make a new CLI release
  • write up draft release announcement in Particle Firmware Updates Thread - copy change log notes
  • when new CLI version is released and firmware release available in Build, publish the announcement
    • merge the release branch back into develop. don't delete the branch - it's used by the compile service.

Post Release Checklist

In the develop branch prepare for the next release:

  • Edit system/inc/system_version.h to bump the SYSTEM_VERSION version constant to reflect the next version.
  • Edit build/version.mk, bumping VERSION= and VERSION_STRING= to the next version

Release Tags and Branches Process

  • When all the features required for a release are merged into develop, create a new release branch release/vX.Y.Z. The branch is feature-frozen and only critical fixes, docs go into that branch.
  • When the release branch is ready for releasing to staging, tag with a release candidate. e.g. v0.5.0-rc.1
  • Iterate on the release, fixing any bugs that are found, and tagging new release candidates for pushing to staging.
  • Once the release passes all tests on staging, tag with the final release number X.Y.Z and push to production git tag v0.5.0 and git push origin v0.5.0.
  • Merge the release branch back into develop. don't delete the branch - it's used by the compile service.

MFG Image

// NOTE THE FOLLOWING APPEARS TO BE OUTDATED
- view `hal/src/photon/wiced_test_mfg_combined.mk`
  - be sure to follow the instructions at the top of that file on setting up the photon-wiced repo and switching to the correct branch in that repo
- on OSX, `cd hal/src/photon` and run `./make_combined.sh PLATFORM_ID=6` this will produce the release artifacts in `build/target/release-<VERSION>/`  (you may need to edit `make_combined.sh` to set the location if the firmware and photon-wiced repo.) 
- in order to produce the latest `wl.exe` for USI (which reports the firmware version), run `make -f wiced_test_mfg_combined.mk PLATFORM_ID=6` on Windows.

There's also this checklist for MFG image https://particle.faqt.co/faqt/4906

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.