Repository: mesos Updated Branches: refs/heads/master 0672c27c9 -> 8c564db51
Copy-edited versioning doc. Project: http://git-wip-us.apache.org/repos/asf/mesos/repo Commit: http://git-wip-us.apache.org/repos/asf/mesos/commit/8c564db5 Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/8c564db5 Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/8c564db5 Branch: refs/heads/master Commit: 8c564db51961dcc016f0206bded1c7b7b648d824 Parents: 0672c27 Author: Neil Conway <neil.con...@gmail.com> Authored: Wed May 17 13:59:17 2017 -0700 Committer: Neil Conway <neil.con...@gmail.com> Committed: Wed May 17 15:06:31 2017 -0700 ---------------------------------------------------------------------- docs/versioning.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/mesos/blob/8c564db5/docs/versioning.md ---------------------------------------------------------------------- diff --git a/docs/versioning.md b/docs/versioning.md index 178026c..70feb53 100644 --- a/docs/versioning.md +++ b/docs/versioning.md @@ -9,14 +9,14 @@ The Mesos versioning and release policy gives operators and developers clear gui * Making modifications to the existing APIs without affecting backward compatibility. * How long a Mesos API will be supported. -* Upgrading the Mesos installation across release versions. +* Upgrading a Mesos installation across release versions. -This document describes the release strategy for Mesos post 1.0.0 release. This might not be applicable for pre 1.0 releases, though parts of the strategy (e.g., release cadence) might be tested for in pre 1.0 releases. +This document describes the release strategy for Mesos post 1.0.0 release. ## Release Schedule -Mesos releases are time based and not feature based. This gives users and developers a predictable cadence to consume and produce features. +Mesos releases are time-based, not feature-based. This gives users and developers a predictable cadence to consume and produce features. If a feature is not ready by the time a release is cut, that feature should be disabled. This means that features should be developed in such a way that they are opt-in by default and can be easily disabled (e.g., flag). A feature completion should not typically block a release. @@ -24,7 +24,7 @@ A new Mesos release is cut every **2 months**. The versioning scheme is [SemVer] Every (minor) release is a stable release and recommended for production use. This means a release candidate will go through rigorous testing (unit tests, integration tests, benchmark tests, cluster tests, scalability etc) before being officially released. In the rare case that a regular release is not deemed stable, a patch release will be released that will stabilize it. -Every (minor) release is supported for a period of **6 months**. Support means fixing of *critical issues* that affect the release. Once a release reaches End Of Life (i.e., support period has ended) no more patch releases will be made for that release. Note that this is not related to backwards compatibility guarantees and deprecation periods (discussed later). +Every (minor) release is supported for a period of **6 months**. Support means fixing of *critical issues* that affect the release. Once a release reaches End Of Life (i.e., support period has ended), no more patch releases will be made for that release. Note that this is not related to backwards compatibility guarantees and deprecation periods (discussed later). Which issues are considered critical? @@ -38,7 +38,7 @@ Whether an issue is considered critical or not is sometimes subjective. In some Once an issue is deemed critical, it will be fixed in only those **affected** releases that are still **supported**. This is called a patch release and increments the patch version by 1 (e.g., 1.2.1). -Patch releases are normally done once **a month**. +Patch releases are normally done **once per month**. If a particular issue is affecting a user and the user cannot wait until the next scheduled patch release, they can request an off-schedule patch release for a specific supported version. This should be done by sending an email to the dev list. @@ -52,7 +52,7 @@ All stable releases will be loosely compatible. Loose compatibility means: > NOTE: The compatibility guarantees do not apply to modules yet. See Modules > section below for details. -Note that this means users should be able to upgrade (as long as they are not depending on deprecated / removed features) Mesos master or agent from a stable release version N directly to another stable release version M without having to go through intermediate release versions. For the purposes of upgrades, a stable release means the release with the latest patch version. For example, among 1.2.0, 1.2.1, 1.3.0, 1.4.0, 1.4.1 releases 1.2.1, 1.3.0 and 1.4.1 are considered stable and so a user should be able to upgrade from 1.2.1 directly to 1.4.1. Look at the API compatability section below for how frameworks can do seamless upgrades. +This means users should be able to upgrade (as long as they are not depending on deprecated / removed features) Mesos master or agent from a stable release version N directly to another stable release version M without having to go through intermediate release versions. For the purposes of upgrades, a stable release means the release with the latest patch version. For example, among 1.2.0, 1.2.1, 1.3.0, 1.4.0, 1.4.1 releases 1.2.1, 1.3.0 and 1.4.1 are considered stable and so a user should be able to upgrade from 1.2.1 directly to 1.4.1. Look at the API compatability section below for how frameworks can do seamless upgrades. The deprecation period for any given feature will be **6 months**. Having a set period allows Mesos developers to not indefinitely accrue technical debt and allows users time to plan for upgrades.
