From 125c2762f1b0465b0e98b1a7f322d3c48767854f Mon Sep 17 00:00:00 2001 From: Steven Ren Date: Fri, 18 Oct 2019 10:28:38 +0800 Subject: [PATCH] Document the versioning and release process, also updating the SECURITY.md to refer to the RELEASES.md. Signed-off-by: Steven Ren --- RELEASES.md | 28 ++++++++++++++++++++++++++++ SECURITY.md | 14 +------------- 2 files changed, 29 insertions(+), 13 deletions(-) create mode 100644 RELEASES.md diff --git a/RELEASES.md b/RELEASES.md new file mode 100644 index 000000000..c36332764 --- /dev/null +++ b/RELEASES.md @@ -0,0 +1,28 @@ +# Versioning and Release +This document describes the versioning and release process of Harbor. This document is a living document, contents will be updated according to each releases. + +## 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 `..`. 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". + +### Major and Minor Releases +Major and minor releases of Harbor will be branched from master when the release reaches to `RC(release candidate)` state. The branch format should follow `release-..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..` and should be made with command `git tag -s v..`. The release cadency is around 3 months, might be adjusted based on open source event, but will communicate it clearly. + +### Patch releases +Patch releases are based on the major/minor release branch, the release cadency for patch release of recent minor release is one month to solve critical community and security issues. The cadency for patch release of recent minus two minor releases are on-demand driven based on the severity of the issue to be fixed. + +### Pre-releases +`Pre-releases:mainly the different RC builds` will be compiled from their corresponding branches. Please note they are done to assist in the stabilization process, no guarantees are provided. + +### Minor Release Support Matrix +| Version | Supported | +| ------- | ------------------ | +| Harbor v1.7.x | :white_check_mark: | +| Harbor v1.8.x | :white_check_mark: | +| Harbor v1.9.x | :white_check_mark: | + +### Upgrade path and support policy +The upgrade path for Harbor is (1) 1.0.x patch releases are always compatible with its major and minor version. For example, previous released 1.8.x can be upgraded to most recent 1.8.4 release. (2) Harbor only supports two previous minor releases to upgrade to current minor release. For example, 1.9.0 will only support 1.7.0 and 1.8.0 to upgrade from, 1.6.0 to 1.9.0 is not supported. One should upgrade to 1.8.0 first, then to 1.9.0. +The Harbor project maintains release branches for the three most recent minor releases, each minor release will be maintained for approximately 9 months. There is no mandated timeline for major versions and there are currently no criteria for shipping a new major version (i.e. Harbor 2.0.0). + +### 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. diff --git a/SECURITY.md b/SECURITY.md index bdf41fd4f..173759838 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -2,20 +2,8 @@ Harbor is a large growing community devoted in creating a private enterprise-grade registry for all your cloud native assets. The community has adopted this security disclosure and response policy to ensure we responsibly handle critical issues. ## Supported Versions -This section describes the maximum version skew supported between various Harbor releases. Harbor versions are expressed as **x.y.z**, where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning terminology](https://semver.org/). +The Harbor project maintains release branches for the three most recent minor releases. Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility. Please refer to [RELEASES.md](https://github.com/goharbor/harbor/blob/master/RELEASES.md) for details. -### Support Policy -The Harbor project maintains release branches for the three most recent minor releases. Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility. Patch releases are cut from those branches at a regular cadence, or as needed. The Harbor project typically has a minor release approximately every 3 months, maintaining each minor release branch for approximately 9 months. - -There is no mandated timeline for major versions and there are currently no criteria for shipping a new major version (i.e. Harbor 2.0.0). - -### Minor Release Support Matrix -| Version | Supported | -| ------- | ------------------ | -| Harbor v1.7.x | :white_check_mark: | -| Harbor v1.8.x | :white_check_mark: | -| Harbor v1.9.x | :white_check_mark: | - ## Reporting a Vulnerability - Private Disclosure Process Security is of the highest importance and all security vulnerabilities or suspected security vulnerabilities should be reported to Harbor privately, to minimize attacks against current users of Harbor before they are fixed. Vulnerabilities will be investigated and patched on the next patch (or minor) release as soon as possible. This information could be kept entirely internal to the project.