root
/
harbor
mirror of https://github.com/goharbor/harbor.git
1
0
Fork 0
Code Issues Actions 23 Packages Projects Releases Wiki Activity

Update RELEASES with version 2.14 

also fix typos and incorrect wording while at it without changing the structure and meaning of the document.
This commit is contained in:
Vadim Bauer 2025-10-01 17:32:49 +02:00
parent c004f2d3e6
commit ac2d19d8da
1 changed files with 34 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
RELEASES.md
View File

@ -1,43 +1,54 @@
# Versioning and Release
This document describes the versioning and release process of Harbor. This document is a living document, it's contents will be updated according to each release.
This document describes the versioning and release process of Harbor. This is a living document and will be updated with each release.
## Releases
Harbor releases will be versioned using dotted triples, similar to [Semantic Version](http://semver.org/). For this specific document, we will refer to the respective components of this triple as `<major>.<minor>.<patch>`. The version number may have additional information, such as "-rc1,-rc2,-rc3" to mark release candidate builds for earlier access. Such releases will be considered as "pre-releases".
Harbor releases use a three-part version number, similar to [Semantic Versioning](http://semver.org/): `<major>.<minor>.<patch>`. The version number may include additional information, such as `-rc1`, `-rc2`, or `-rc3` to indicate release candidate builds for early access. These are considered pre-releases.
### Major and Minor Releases
Major and minor releases of Harbor will be branched from `main` when the release reaches to `RC(release candidate)` state. The branch format should follow `release-<major>.<minor>.0`. For example, once the release `v1.0.0` reaches to RC, a branch will be created with the format `release-1.0.0`. When the release reaches to `GA(General Available)` state, the tag with format `v<major>.<minor>.<patch>` and should be made with the command `git tag -s v<major>.<minor>.<patch>`. The release cadence is around 3 months, might be adjusted based on open source events, but will communicate it clearly.
Major and minor releases are branched from `main` when the release reaches the RC (release candidate) stage. The branch should be named `release-<major>.<minor>.0`. For example, when release `v1.0.0` reaches RC, a branch named `release-1.0.0` was created. When the release reaches GA (General Availability), a tag in the format `v<major>.<minor>.<patch>` should be created using the command `git tag -s v<major>.<minor>.<patch>`. The release cadence is approximately every 3 months, but may be adjusted based on events. Any changes to the cadence will be communicated clearly.
### Patch releases
Patch releases are based on the major/minor release branch, the release cadence for patch release of recent minor release is one month to solve critical community and security issues. The cadence for patch release of recent minus two minor releases are on-demand driven based on the severity of the issue to be fixed.
### Patch Releases
Patch releases are based on the major/minor release branch. The cadence for patch releases of the most recent minor release is one month, to address critical community and security issues. Patch releases for the two previous minor releases are made on demand, depending on the severity of the issues to be fixed.
### Pre-releases
`Pre-releases:mainly the different RC builds` will be compiled from their corresponding branches. Please note that they are done to assist in the stabilization process, no guarantees are provided.
Pre-releases, mainly the different RC builds, are compiled from their corresponding branches. These builds are intended to help with stabilization, but no guarantees are provided.
### Support Policy
The Harbor project maintains the three latest minor releases. Each minor release is supported for approximately 9 months.
### Supported Versions
### Minor Release Support Matrix
| Version | Supported |
|----------------| ------------------ |
|----------------|--------------------|
| Harbor v2.14.x | :white_check_mark: |
| Harbor v2.13.x | :white_check_mark: |
| Harbor v2.12.x | :white_check_mark: |
| Harbor v2.11.x | :white_check_mark: |
| Harbor v2.11.x | :x: |
### Upgrade path and support policy
The upgrade path for Harbor is (1) 2.2.x patch releases are always compatible with its major and minor versions. For example, previous released 2.2.x can be upgraded to most recent 2.2.3 release. (2) Harbor only supports two previous minor releases to upgrade to current minor release. For example, 2.3.0 will only support 2.1.0 and 2.2.0 to upgrade from, 2.0.0 to 2.3.0 is not supported. One should upgrade to 2.2.0 first, then to 2.3.0.
The Harbor project maintains release branches for the three most recent minor releases, each minor release will be maintained for approximately 9 months.
### Upgrade Policy
Upgrades to a new minor release are only supported from the two previous minor releases.
For example, to upgrade to `v2.14.x`, you must be on a `v2.13.x` or `v2.12.x` release.
Upgrading directly from `v2.11.x` to `v2.14.x` is not supported;
you must first upgrade to `v2.12.x`, then to `v2.14.x`.
### Next Release
The activity for next release will be tracked in the [up-to-date project board](https://github.com/orgs/goharbor/projects/1). If your issue is not present in the corresponding release, please reach out to the maintainers to add the issue to the project board.
The activity and release dates of the next release are tracked in the [release plan wiki](https://github.com/goharbor/harbor/wiki/Release-plans).
### Publishing a New Release
The following steps outline what to do when it's time to plan for and publish a release. Depending on the release (major/minor/patch), not all the following items are needed.
The following steps outline what to do when planning and publishing a release. Depending on the type of release (major, minor, or patch), not all steps may be required.
1. Prepare information about what's new in the release.
* For every release, update the documentation for changes that have happened in the release. See the [goharbor/website](https://github.com/goharbor/website) repo for more details on how to create documentation for a release. All documentation for a release should be published by the time the release is out.
* For every release, write release notes. See [previous releases](https://github.com/goharbor/harbor/releases) for examples of what to include in release notes.
* For a major/minor release, write a blog post that highlights new features in the release. Plan to publish this on the same day as the release. Highlight the themes, or areas of focus, for the release. Some examples of themes are security, bug fixes, feature improvements. If there are any new features or workflows introduced in a release, consider writing additional blog posts to help users learn about the new features. Plan to publish these after the release date (all blogs don’t have to be published all at once).
1. Release a new version. Make the new version, docs updates, and blog posts available.
1. Announce the release and thank contributors. We should be doing the following for all releases.
* In all messages to the community include a brief list of highlights and links to the new release blog, release notes, or download location. Also include shoutouts to community members contributions included in the release.
* Send an email to the community via the [mailing list](https://lists.cncf.io/g/harbor-users)
* Post a message in the Harbor [slack channel](https://cloud-native.slack.com/archives/CC1E09J6S)
* Post to social media. Maintainers are encouraged to also post or repost from the Harbor account to help spread the word.
* For every release, update the documentation to reflect changes. See the [goharbor/website](https://github.com/goharbor/website) repo for details on creating release documentation. All documentation should be published by the time the release is out.
* For every release, write release notes. See [previous releases](https://github.com/goharbor/harbor/releases) for examples of what to include.
* For major and minor releases, write a blog post highlighting new features. Plan to publish this on the same day as the release. Highlight the main themes or focus areas, such as security, bug fixes, or feature improvements. If new features or workflows are introduced, consider writing additional blog posts to help users learn about them. These can be published after the release date (not all blogs need to be published at once).
2. Release the new version. Make the new version, documentation updates, and blog posts available.
3. Announce the release and thank contributors. For all releases, do the following:
* In all community messages, include a brief list of highlights and links to the new release blog, release notes, or download location. Also, give shoutouts to community members whose contributions are included in the release.
* Send an email to the community via the [mailing list](https://lists.cncf.io/g/harbor-users).
* Post a message in the Harbor [Slack channel](https://cloud-native.slack.com/archives/CC1E09J6S).
* Post to social media. Maintainers are encouraged to post or repost from the Harbor account to help spread the word.