Skip to content

Build and Release protocol

Jump to bottom
Samie Bee edited this page Nov 6, 2023 · 2 revisions

Build

  1. Use platform specific (ex Win10) instructions to create an installer.

Release

Standard Release

A standard release is one that will be available to all users of Enlighten. All standard releases start as a Release Candidate (RC), and RC's can be promoted to official releases if they are deemed reliable enough. Promoting an RC to an official release will generate an Engineering Change Notification (ECN) within our organization.

The steps for creating a standard release are as follows.

Creating a minor Release Candidate

These instructions are for releases that change only the most minor semantic versioning number. Ex 4.0.6 --> 4.0.7

  1. Create a Pull Request (PR) or series of them which contains desired changes
  2. Request and wait for approval from another author
  3. When everything is merged to main, you may create an additional commit on main containing CHANGELOG.md and common.py version number modifications
  4. Create a tag on main in the Enlighten repository matching the version number, with no prefix/suffix. Ex: 4.0.25
  5. Create a tag on main in the Wasatch.PY repository with a prefix. Ex: enlighten-4.0.25. This should be the same commit that the Enlighten revisions were developed on and tested against.
  6. (Windows) Create an installer using scripts\bootstrap.bat
  7. Optional. Deploy the installer to our website. (See internal wiki)
  8. Create a Github release with a suffix rc. Ex: 4.0.25rc Describe any changes between this and the last standard release. Link to or embed any installers.

Creating a semi-major Release Candidate

These instructions are for creating releases that increment the semi-major semantic versioning number. Ex: 4.0.25 --> 4.1.0

  1. Make a Pull Request from a staging branch (4.1.0-dev) into main
  2. Follow the same steps for minor Release Candidates.

Promoting a Release Candidate to an Official Release

We do not yet have an up-to-date official protocol for this. It will generate an Engineering Change Notification (ECN).

Internal Build (non-release)

Internal builds should not have version numbers. These may be used to check on behaviors that may vary depending on whether the program is run from source or from an installer. In place of a version number, internal builds should contain the date and commit number in short form: YYYYMMDDHHMM-commit. The date and time is set to EST. We do not yet have an internal build option in our build script.

Downstream Patch

Downstream patches contain features or elements that are only intended for specific users or operating systems. Most notably these should not be merged to main before releasing. It's not yet clear to me how these should be versioned. One example of a downstream patch in the past was from the ubu-py37 branch. It was 4.0.12 + changes to make it run on Ubuntu. It was versioned simply as the Ubuntu version of 4.0.12. In the event of distributing downstream to specific users we might do something similar: version 4.3.5 with downstream support for situation/company X. Typically we rather use plugins for user-specific cases.

Clone this wiki locally