Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update release guidelines #546

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Update release guidelines #546

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
79 changes: 69 additions & 10 deletions docs/community/maintainers/release-process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,27 +37,72 @@ YYYY-MM-releaseNumber
`releaseNumber` represents the current release for that month, starting at `1`. Anything above `1` represents a [hotfix (patch) release](#hotfixes).
:::

## Release Tags

- `YYYY-MM-releaseNumber`: This format represents the tag for each specific release.

:::caution
For the release tag, there should be NO prepended `v`
Do **not** prepend a `v` to the release tag.
:::

For example, the first Nebari CalVer release was `2022.10.1`. If a hotfix release was needed in the same month, we increment the `releaseNumber` by 1, which would be `2022.10.2` (_this is to illustrate how the increment works, this release does not exist._)
For example, the first Nebari CalVer release was `2022.10.1`. If a hotfix were needed in the same month, you would increment the `releaseNumber` by 1 to get `2022.10.2`. (_Note: This is just an illustration; this release does not actually exist._)

Comment on lines +48 to 49
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be rewritten since that's not how calver works

## Branching strategy
## Branching Strategy

We use the following guidelines to manage `git` branches by assigning certain roles to particular branches.
At Nebari, we embrace a straightforward branching strategy to keep our development process simple and efficient. We follow the [GitHub flow](https://docs.github.com/en/get-started/using-github/github-flow) model, which revolves around a single `main` branch for active development.

- [`main`](https://github.com/nebari-dev/nebari/tree/main) - Represents the active development branch and is the _default_ branch on the GitHub repository.
### Branch Roles

## Release Tags
We designate specific roles to our Git branches for clarity and organization:

- [`main`](https://github.com/nebari-dev/nebari/tree/main): This is the default branch where all new features and fixes are merged. It represents the active development state of the project.

For hotfix releases, we create a new branch from the `main` branch using the naming convention `hotfix-YYYY-MM-releaseNumber`. This branch is specifically for implementing necessary changes for the hotfix and is deleted after the release is completed.

### Release Process

The Nebari release process is a structured workflow that ensures the quality and reliability of each release. The process consists of the following key steps:

1. **Preparation**: Identify the changes to include in the release and associate them
with the appropriate milestone. Assign a Nebari core maintainer as the "Release
Captain" and open a release checklist issue to track the process.

2. **Release Candidate**: After merging all necessary pull requests, the Release Captain
creates an initial Release Candidate using the pre-release option in the GitHub
releases panel. A review checklist issue is also opened to ensure that all changes
are correctly included in the release. This could be a iterative process, with
multiple release candidates being created in case of new changes or fixes being needed.

3. **Testing and Verification**: Complete the review checklist to confirm that all
changes function as expected and that major services perform optimally. The Release
Captain assigns owners to each checklist item to ensure accountability.

- `YYYY-MM-releaseNumber` - Represents the tag for a particular release.
4. **Finalizing the Release**: Upon successful testing, the Release Captain updates the
release notes and increments the version number in the `constants.py` file. The final
release is then published, and the release checklist issue is updated with the final
details.

### Process
For a detailed guide on the release process, refer to the [release checklist template](https://github.com/nebari-dev/nebari/blob/main/.github/ISSUE_TEMPLATE/release-checklist.md).

The release process is captured in the [release checklist template](https://github.com/nebari-dev/nebari/blob/main/.github/ISSUE_TEMPLATE/release-checklist.md). In the event that a patch or hotfix release is needed, release process is the same as outlined above.
### Hotfixes and Patch Releases

## Related packages
If a patch or hotfix release is necessary, the process mirrors the standard release steps with a key difference:

- The Release Captain creates a new **hotfix branch** (see the convention above) from the previous release **tag**.
- Necessary changes are cherry-picked into this hotfix branch.
- The final release is published following the standard procedure.

This approach ensures that critical fixes are efficiently addressed without disrupting
the main development workflow.

:::note
Hotfix releases are rare and are only used to address critical issues that cannot wait
for the next scheduled release, they are usually associated with
[broken](https://conda-forge.org/docs/maintainer/updating_pkgs/#removing-broken-packages)
or [yanked](https://pypi.org/help/#yanked) releases. And should be delivered as soon as possible.
:::
Comment on lines +98 to +103
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to include dedicated section about broken releases, and how to proceed in each mirror


## Related packages and repositories

### nebari-dask

Expand All @@ -70,3 +115,17 @@ The release process is captured in the [release checklist template](https://gith
The [`nebari-docker-images`](https://github.com/nebari-dev/nebari-docker-images) repo contains the Dockerfiles for the JupyterHub, JupyterLab, and Dask-Gateway Kubernetes deployments. This repo also contains the workflow needed to build and push them the images to [github.com/orgs/nebari-dev/packages](https://github.com/orgs/nebari-dev/packages) and [quay.io/organization/nebari](https://quay.io/organization/nebari).

> These images are built and tagged with the same version number of the corresponding `nebari` release. Included in the release checklist linked above.

If there were changes to the following packages, handle their releases before cutting a new release for Nebari

### nebari-workflow-controller

The [`nebari-workflow-controller`](https://github.com/nebari-dev/nebari-workflow-controller)
is a [kubernetes admission
controller](https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/)
to enable volumeMount permissions on Argo Workflows on Nebari and provide a convenience
method for deploying jupyterlab-like workflows for users.

### argo-jupyter-scheduler

The [`argo-jupyter-scheduler`](https://github.com/nebari-dev/argo-jupyter-scheduler) is a plugin for the [Jupyter-Scheduler](https://jupyter-scheduler.readthedocs.io/en/latest/index.html) extension in JupyterLab. It allows you to submit long-running notebooks to run asynchronously without needing to keep your JupyterLab server active. You can also schedule notebooks to run at specified times.
Loading