Feathr Overall Release Guide

This document describes all the release process for the development team.

Prerequisites

• Make sure nightly CI tests are passed.
• Make sure notebook nightly tests are passed.
• Make sure all the active PRs related to the release are merged.

When to Release

The release process is triggered by the release manager. The release manager will decide when to release with following steps:

1. Ensure Prerequisites are met.
2. Creation of Release Candidate(rc) on GitHub.
3. Bug Bash.
4. Creation of Release on GitHub.
5. Post Release announcement.

Release Versioning

• Major and minor version: X.Y.Z
• Release Candidate: X.Y.Z-rcN

Writing Release Note

Write a release note following past examples here. Read through the commit log to identify the commits after last release to include in the release note. Here are the major things to include

• Highlights of the release
• Improvements and changes of this release
• New contributors of this release

Code Changes

Before the release candidate or release is made, the version needs to be updated in following places

• gradle.properties - For Maven release version
• version.py - For Feathr version
• conf.py - For documentation version
• feathr_config.yaml - To set the spark runtime location for Azure Synapse and Azure Databricks used by test suite. Please update all .yaml files under this path.
• package.json - For Feathr UI version
• package-lock.json - For Feathr UI version
• README.md - Update docker image version in the homepage README.
• quickstart_local_sandbox.md - Update docker image version in the sandbox quickstart guide.

Following file should only be updated for release, which means should be skipped for release candidate.

• azure_resource_provision.json - To set the deployment template to pull the latest release image.

Release Branches

Each major and minor release should have a release branch. The release branch should be named as releases/vX.Y.Z or releases/vX.Y.Z-rcN where X.Y.Z is the release version. The release branch should be created from the main branch. See past release branches here.

Release Tags

Once the release branch is created, a release tag should be created from the release branch. The release tag should be named as vX.Y.Z or vX.Y.Z-rcN where X.Y.Z is the release version. See past release tags here.

Triggering automated release pipelines

Once the release branch and release tag are created, the release pipelines will be triggered automatically. The release pipelines will build the release artifacts and publish them to DockerHub, Maven and PyPI.

1. Automated workflow to build and publish for Feathr Registry docker images to DockerHub. Triggers - Nightly or branch with name pattern “releases/*”

2. Automated workflow for publishing Python package to PyPI. Triggers - branch with name pattern “releases/*”

3. Automated workflow for publishing runtime jar to maven/sonatype repository.

4. Automated workflow for uploading runtime jar to Azure storage.

Release PyPI

The automated workflow should take care of this, you can check under actions to see the triggered run and results. For manual steps, see Python Package Release Guide

Push to Docker Hub

The automated workflow should take care of this, you can check under actions to see the triggered run and results. For manual steps, see How to build and push feathr registry docker image

Release Maven

The automated workflow should take care of this, you can check under actions to see the triggered run and results. For manual steps, see Feathr Developer Guide for publishing to maven

Testing

Run one of the sample notebook as it uses the latest package from Maven and PyPi.

Announcement

Please announce the release in our #general Slack channel.