Release strategy: alpha, beta, rc by tiran · Pull Request #1758 · instructlab/instructlab

tiran · Jul 17, 2024

Proposal for using alpha, beta, and RCs.

Checklist:

Commit Message Formatting: Commit titles and messages follow guidelines in the
conventional commits.
Changelog updated with breaking and/or notable changes for the next minor release.
Documentation has been updated, if necessary.
Unit tests have been added, if necessary.
Integration tests have been added, if necessary.

bjhargrave · Jul 17, 2024

docs/release-strategy.md

 ## Git Branches and Tags

-Every `X.Y` release stream gets a new branch.
+Every `X.Y` release stream gets a new branch `release-X.Y`. The release branch is created with first beta, release candidate, or final `X.Y.0` release.


The branch name, release-X.Y, differs from the name below release-vX.Y

good catch!

Yup, release branches are of the form release-vX.Y

This is the point I made in the CLI call this week. When we are ready to make an RC build, we need to make it from a release branch and not main. This then opens up main for work. I am not as concerned about beta releases from main but I am also ok with saying beta releases need to come from a release branch.

bjhargrave · Jul 17, 2024

docs/release-strategy.md

+1. Validate the release branch with an [E2E test](ci.md).
+1. Create a new release on GitHub targeting the release branch and using the latest Y-Stream tag as the previous release (e.g. `0.15.1` precedes `0.16.0a1`).
+
+### Y-Stream (`X.Y.0`, `X.Y.0b1`, `X.Y.0rc1`)


Suggested change

### Y-Stream (`X.Y.0`, `X.Y.0b1`, `X.Y.0rc1`)

### Y-Stream (`X.Y.0b1`, `X.Y.0rc1`, `X.Y.0`)

I would order these in the proper order.

dhellmann · Jul 17, 2024

docs/release-strategy.md


+Alpha releases are tagged as `vX.Y.Za1`, `vX.Y.Za2`, and so on. Alpha releases are created from the main branch, **not** from a `release-X.Y` branch.
+
+Beta releases are tagged as `vX.Y.Zb1`, `vX.Y.Zb2`, and so on from `release-X.Y` branch.


I've always used a tag as the base of a branch, too. So, tag a beta, make the release branch from the same point, then future tags for that release series are on the branch and clearly after only that initial branching version and not intermingled with pre-releases of other versions on the main branch.

dhellmann · Jul 17, 2024

docs/release-strategy.md

 ## Git Branches and Tags

-Every `X.Y` release stream gets a new branch.
+Every `X.Y` release stream gets a new branch `release-X.Y`. The release branch is created with first beta, release candidate, or final `X.Y.0` release.


Do we need alphas, betas, and RCs? We want an alpha today to avoid breaking community users while we test some downstream build machinery. The pre-release type doesn't really matter for that, so we could just always use alphas. Maybe there's a reason to use different types upstream, though?

I would like to start using RCs from here on out with a couple of days of testing between rc1 and final.

alphas are cut from the main branch and can have known bugs

betas are cut from a release branch and should have stable API and requirements

rcs should be stable. When everything goes right, then 1.2.3rc1 tag will become the 1.2.3 tag without any modifications.

OK, that makes sense.

russellb

+1 to the clarification that we do alphas from main

docs/release-strategy.md

Proposal for using alpha, beta, and RCs. Signed-off-by: Christian Heimes <cheimes@redhat.com>

nathan-weinberg · Jul 18, 2024

docs/release-strategy.md


 Z-stream releases are meant for critical bug and documentation fixes. Z-stream releases are cut as maintainers see fit.

+A final release may be preceded by a pre-release (alpha `X.Y.ZaN`, beta `X.Y.ZbN`, or release candidate `X.Y.ZrcN`). PyPI and pip automatically recognize them as pre-release. Pip ignores pre-releases unless the user explicitly requests a pre-release with `pip install --pre` or `pip install instructlab==0.16.0a1`.


Suggested change

A final release may be preceded by a pre-release (alpha `X.Y.ZaN`, beta `X.Y.ZbN`, or release candidate `X.Y.ZrcN`). PyPI and pip automatically recognize them as pre-release. Pip ignores pre-releases unless the user explicitly requests a pre-release with `pip install --pre` or `pip install instructlab==0.16.0a1`.

A release may be preceded by a pre-release, e.g.

- Alpha (`X.Y.ZaN`)

- Beta (`X.Y.ZbN`)

- Release Candidate (`X.Y.ZrcN`)

PyPI and pip automatically recognize these types of tags as pre-release. Pip ignores pre-releases unless the user explicitly requests a pre-release with `pip install --pre` or `pip install instructlab==0.16.0a1`.

nathan-weinberg · Jul 18, 2024

docs/release-strategy.md

 ## Git Branches and Tags

-Every `X.Y` release stream gets a new branch.
+Every `X.Y` release stream gets a new branch `release-X.Y`. The release branch is created with first beta, release candidate, or final `X.Y.0` release.


Yup, release branches are of the form release-vX.Y

nathan-weinberg · Jul 18, 2024

docs/release-strategy.md

+1. Announce release via the following:
+    - The `#announce` channel on Slack
+    - The `announce` mailing list


Do we want to do as broad of an announcement for pre-releases as we do regular releases?

ktam3 · Aug 21, 2024

@tiran - could you take this out of draft pls

mergify · Nov 18, 2024

This pull request has merge conflicts that must be resolved before it can be
merged. @tiran please rebase it. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

mergify · Jan 6, 2025

This pull request has merge conflicts that must be resolved before it can be
merged. @tiran please rebase it. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

courtneypacheco · Jan 7, 2025

@tiran Are you planning to complete this release strategy? If not or you don't have the cycles currently, would you mind if I rebased and took it over for you?

mergify · Mar 27, 2025

This pull request has merge conflicts that must be resolved before it can be merged. @tiran please rebase it. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

mergify · Apr 28, 2025

This pull request has merge conflicts that must be resolved before it can be merged. @tiran please rebase it. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

github-actions · Jun 28, 2025

This pull request has been automatically marked as stale because it has not had activity within 60 days. It will be automatically closed if no further activity occurs within 30 days.

mergify bot added documentation Improvements or additions to documentation ci-failure PR has at least one CI failure labels Jul 17, 2024

tiran force-pushed the release-alpha branch from b30882c to 40e317c Compare July 17, 2024 15:10

mergify bot removed the ci-failure PR has at least one CI failure label Jul 17, 2024

bjhargrave reviewed Jul 17, 2024

View reviewed changes

dhellmann reviewed Jul 17, 2024

View reviewed changes

russellb reviewed Jul 17, 2024

View reviewed changes

leseb reviewed Jul 17, 2024

View reviewed changes

docs/release-strategy.md Show resolved Hide resolved

Release strategy: alpha, beta, rc

ed24cfb

Proposal for using alpha, beta, and RCs. Signed-off-by: Christian Heimes <cheimes@redhat.com>

tiran force-pushed the release-alpha branch from 40e317c to ed24cfb Compare July 17, 2024 15:46

nathan-weinberg self-requested a review July 17, 2024 17:47

nathan-weinberg reviewed Jul 18, 2024

View reviewed changes

nathan-weinberg requested review from alinaryan and jaideepr97 July 18, 2024 13:29

nathan-weinberg added this to the 0.19.0 milestone Aug 15, 2024

ktam3 modified the milestones: 0.19.0, 0.20.0 Oct 1, 2024

nathan-weinberg mentioned this pull request Oct 7, 2024

Add document detailing release strategy for libraries instructlab/dev-docs#125

Merged

nathan-weinberg mentioned this pull request Oct 15, 2024

Document policy for pinning / upper+lower bounding dependencies #2454

Closed

ktam3 modified the milestones: 0.20.0, 0.21.0 Oct 31, 2024

ktam3 modified the milestones: 0.21.0, 0.23.0 Nov 18, 2024

mergify bot added the needs-rebase This Pull Request needs to be rebased label Nov 18, 2024

mergify bot removed the needs-rebase This Pull Request needs to be rebased label Jan 6, 2025

mergify bot added the needs-rebase This Pull Request needs to be rebased label Jan 6, 2025

nathan-weinberg modified the milestones: 0.23.0, 0.24.0 Jan 27, 2025

nathan-weinberg mentioned this pull request Jan 27, 2025

deps: cap dependencies for 0.23.0 release #3015

Merged

6 tasks

courtneypacheco mentioned this pull request Jan 27, 2025

Review and update the current release strategy #3019

Closed

mergify bot removed the needs-rebase This Pull Request needs to be rebased label Mar 27, 2025

mergify bot added the needs-rebase This Pull Request needs to be rebased label Mar 27, 2025

mergify bot removed the needs-rebase This Pull Request needs to be rebased label Apr 28, 2025

mergify bot added the needs-rebase This Pull Request needs to be rebased label Apr 28, 2025

github-actions bot added the stale label Jun 28, 2025

nathan-weinberg closed this Jul 2, 2025

	### Y-Stream (`X.Y.0`, `X.Y.0b1`, `X.Y.0rc1`)
	### Y-Stream (`X.Y.0b1`, `X.Y.0rc1`, `X.Y.0`)


		Alpha releases are tagged as `vX.Y.Za1`, `vX.Y.Za2`, and so on. Alpha releases are created from the main branch, not from a `release-X.Y` branch.

		Beta releases are tagged as `vX.Y.Zb1`, `vX.Y.Zb2`, and so on from `release-X.Y` branch.


		Z-stream releases are meant for critical bug and documentation fixes. Z-stream releases are cut as maintainers see fit.

		A final release may be preceded by a pre-release (alpha `X.Y.ZaN`, beta `X.Y.ZbN`, or release candidate `X.Y.ZrcN`). PyPI and pip automatically recognize them as pre-release. Pip ignores pre-releases unless the user explicitly requests a pre-release with `pip install --pre` or `pip install instructlab==0.16.0a1`.

-A final release may be preceded by a pre-release (alpha `X.Y.ZaN`, beta `X.Y.ZbN`, or release candidate `X.Y.ZrcN`). PyPI and pip automatically recognize them as pre-release. Pip ignores pre-releases unless the user explicitly requests a pre-release with `pip install --pre` or `pip install instructlab==0.16.0a1`.
+A release may be preceded by a pre-release, e.g.
+- Alpha (`X.Y.ZaN`)
+- Beta (`X.Y.ZbN`)
+- Release Candidate (`X.Y.ZrcN`)
+PyPI and pip automatically recognize these types of tags as pre-release. Pip ignores pre-releases unless the user explicitly requests a pre-release with `pip install --pre` or `pip install instructlab==0.16.0a1`.

Search code, repositories, users, issues, pull requests...

Comments

Conversation

tiran commented Jul 17, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

russellb left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ktam3 commented Aug 21, 2024

Uh oh!

mergify bot commented Nov 18, 2024

Uh oh!

mergify bot commented Jan 6, 2025

Uh oh!

courtneypacheco commented Jan 7, 2025

Uh oh!

mergify bot commented Mar 27, 2025

Uh oh!

mergify bot commented Apr 28, 2025

Uh oh!

github-actions bot commented Jun 28, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants