User Tools

Site Tools


How to create a minor release


  • Properly mark where a v-prefixed version and a non v-prefixed version is used
  • Properly use sample version numbers everywhere
  • Put multiple commands into multiple lines.


For building the release, a valid GnuPG key is required. In addition two scripts are used for easy tagging and creating the changelog.

Preparing the Sources

  1. Ensure your source checkout is up to date
  2. Create the signed tags./ -k <gpg key id> -v <new_version>
  3. Review the changes git log -p -2 git show <new_version>
  4. Push the changes to the git repository git push origin lede-17.01; git push –follow-tags origin refs/tags/v17.01.3:refs/tags/v17.01.3

Building the Release

To trigger a full release build, you need to

  1. Log in to the release buildbot
  2. Go to “Builders”
  3. Populate the reason field (e.g. “trigger release build”)
  4. Populate the first “name” field with “tag”, and the “value” field with the release tag name without the v. It should show something along reason “Trigger release build”, name[0] = tag, value[0] = 17.01.3.
  5. Click “Force All Builds”

This will take about 12 hours.

In the mean time, prepare the changelog. Run ./ <previous_release>..<new_release> > template.txt to generate the changelog. Verify that the changelog was generated correctl,y remove the “(WIP)” from the title and put them it

Announcing the Release

Once the release build is finished an tested, it can be announced.

  1. Update these pages to include the new release:
  2. Add a pinned forum topic. Use as a template. After 4 - 8 weeks, the topic can be unpinned.
docs/guide-developer/cutting-minor-releases.txt · Last modified: 2019/07/03 19:10 by tmomas