You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mesos.apache.org by gi...@apache.org on 2018/04/11 19:11:01 UTC
mesos-site git commit: Updated the website built from mesos SHA:
7097eec.
Repository: mesos-site
Updated Branches:
refs/heads/asf-site 2056236e3 -> 37269e868
Updated the website built from mesos SHA: 7097eec.
Project: http://git-wip-us.apache.org/repos/asf/mesos-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/mesos-site/commit/37269e86
Tree: http://git-wip-us.apache.org/repos/asf/mesos-site/tree/37269e86
Diff: http://git-wip-us.apache.org/repos/asf/mesos-site/diff/37269e86
Branch: refs/heads/asf-site
Commit: 37269e868bef1632f718d8ed6997aaa8897fa4d4
Parents: 2056236
Author: jenkins <bu...@apache.org>
Authored: Wed Apr 11 19:10:58 2018 +0000
Committer: jenkins <bu...@apache.org>
Committed: Wed Apr 11 19:10:58 2018 +0000
----------------------------------------------------------------------
content/blog/feed.xml | 2 +-
.../index.html | 2 +-
content/documentation/latest/versioning/index.html | 12 +++++-------
content/documentation/versioning/index.html | 12 +++++-------
4 files changed, 12 insertions(+), 16 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/mesos-site/blob/37269e86/content/blog/feed.xml
----------------------------------------------------------------------
diff --git a/content/blog/feed.xml b/content/blog/feed.xml
index 8bbaaff..741200a 100644
--- a/content/blog/feed.xml
+++ b/content/blog/feed.xml
@@ -292,7 +292,7 @@ To learn more about CSI work in Mesos, you can dig into the design document <
</ul>
-<p>If you are a user and would like to suggest some areas for performance improvement, please let us know by emailing <a href="&#109;&#97;&#x69;&#108;&#x74;&#x6f;&#58;&#100;&#x65;&#118;&#x40;&#x61;&#x70;&#x61;&#x63;&#104;&#x65;&#x2e;&#109;&#101;&#115;&#111;&#x73;&#x2e;&#111;&#x72;&#103;">&#x64;&#x65;&#118;&#64;&#x61;&#112;&#x61;&#x63;&#x68;&#x65;&#x2e;&#x6d;&#101;&#115;&#111;&#x73;&#x2e;&#111;&#x72;&#103;</a>.</p>
+<p>If you are a user and would like to suggest some areas for performance improvement, please let us know by emailing <a href="&#109;&#x61;&#x69;&#x6c;&#x74;&#x6f;&#x3a;&#x64;&#101;&#x76;&#64;&#97;&#x70;&#97;&#99;&#104;&#101;&#x2e;&#x6d;&#x65;&#x73;&#x6f;&#115;&#x2e;&#x6f;&#114;&#x67;">&#100;&#x65;&#x76;&#x40;&#x61;&#x70;&#97;&#x63;&#104;&#x65;&#46;&#x6d;&#x65;&#115;&#x6f;&#115;&#x2e;&#x6f;&#114;&#x67;</a>.</p>
</content>
</entry>
http://git-wip-us.apache.org/repos/asf/mesos-site/blob/37269e86/content/blog/performance-working-group-progress-report/index.html
----------------------------------------------------------------------
diff --git a/content/blog/performance-working-group-progress-report/index.html b/content/blog/performance-working-group-progress-report/index.html
index 2811029..9782a3c 100644
--- a/content/blog/performance-working-group-progress-report/index.html
+++ b/content/blog/performance-working-group-progress-report/index.html
@@ -238,7 +238,7 @@
</ul>
-<p>If you are a user and would like to suggest some areas for performance improvement, please let us know by emailing <a href="mailto:dev@apache.mesos.org">dev@apache.mesos.org</a>.</p>
+<p>If you are a user and would like to suggest some areas for performance improvement, please let us know by emailing <a href="mailto:dev@apache.mesos.org">dev@apache.mesos.org</a>.</p>
</div>
</div>
http://git-wip-us.apache.org/repos/asf/mesos-site/blob/37269e86/content/documentation/latest/versioning/index.html
----------------------------------------------------------------------
diff --git a/content/documentation/latest/versioning/index.html b/content/documentation/latest/versioning/index.html
index 5c2c4fc..d282deb 100644
--- a/content/documentation/latest/versioning/index.html
+++ b/content/documentation/latest/versioning/index.html
@@ -122,15 +122,15 @@
<h2>Release Schedule</h2>
-<p>Mesos releases are time-based, not feature-based. This gives users and developers a predictable cadence to consume and produce features.</p>
+<p>Mesos releases are time-based, though we do make limited adjustments to the release schedule to accommodate feature development. This gives users and developers a predictable cadence to consume and produce features, while ensuring that each release can include the developments that users are waiting for.</p>
-<p>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.</p>
+<p>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).</p>
-<p>A new Mesos release is cut every <strong>2 months</strong>. The versioning scheme is <a href="http://semver.org">SemVer</a>. Typically, the minor release version is incremented by 1 (e.g., 1.1, 1.2, 1.3 etc) for every release, unless it is a major release.</p>
+<p>A new Mesos release is cut approximately every <strong>3 months</strong>. The versioning scheme is <a href="http://semver.org">SemVer</a>. Typically, the minor release version is incremented by 1 (e.g., 1.1, 1.2, 1.3 etc) for every release, unless it is a major release.</p>
-<p>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.</p>
+<p>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.</p>
-<p>Every (minor) release is supported for a period of <strong>6 months</strong>. Support means fixing of <em>critical issues</em> 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).</p>
+<p>At any given time, 3 releases are supported: the latest release and the two prior. Support means fixing of <em>critical issues</em> that affect the release. Once an issue is deemed critical, it will be fixed in only those <strong>affected</strong> releases that are still <strong>supported</strong>. This is called a patch release and increments the patch version by 1 (e.g., 1.2.1). 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).</p>
<p>Which issues are considered critical?</p>
@@ -145,8 +145,6 @@
<p>Whether an issue is considered critical or not is sometimes subjective. In some cases it is obvious and sometimes it is fuzzy. Users should work with committers to figure out the criticality of an issue and get agreement and commitment for support.</p>
-<p>Once an issue is deemed critical, it will be fixed in only those <strong>affected</strong> releases that are still <strong>supported</strong>. This is called a patch release and increments the patch version by 1 (e.g., 1.2.1).</p>
-
<p>Patch releases are normally done <strong>once per month</strong>.</p>
<p>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.</p>
http://git-wip-us.apache.org/repos/asf/mesos-site/blob/37269e86/content/documentation/versioning/index.html
----------------------------------------------------------------------
diff --git a/content/documentation/versioning/index.html b/content/documentation/versioning/index.html
index c77e3f7..2d0f62b 100644
--- a/content/documentation/versioning/index.html
+++ b/content/documentation/versioning/index.html
@@ -122,15 +122,15 @@
<h2>Release Schedule</h2>
-<p>Mesos releases are time-based, not feature-based. This gives users and developers a predictable cadence to consume and produce features.</p>
+<p>Mesos releases are time-based, though we do make limited adjustments to the release schedule to accommodate feature development. This gives users and developers a predictable cadence to consume and produce features, while ensuring that each release can include the developments that users are waiting for.</p>
-<p>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.</p>
+<p>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).</p>
-<p>A new Mesos release is cut every <strong>2 months</strong>. The versioning scheme is <a href="http://semver.org">SemVer</a>. Typically, the minor release version is incremented by 1 (e.g., 1.1, 1.2, 1.3 etc) for every release, unless it is a major release.</p>
+<p>A new Mesos release is cut approximately every <strong>3 months</strong>. The versioning scheme is <a href="http://semver.org">SemVer</a>. Typically, the minor release version is incremented by 1 (e.g., 1.1, 1.2, 1.3 etc) for every release, unless it is a major release.</p>
-<p>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.</p>
+<p>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.</p>
-<p>Every (minor) release is supported for a period of <strong>6 months</strong>. Support means fixing of <em>critical issues</em> 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).</p>
+<p>At any given time, 3 releases are supported: the latest release and the two prior. Support means fixing of <em>critical issues</em> that affect the release. Once an issue is deemed critical, it will be fixed in only those <strong>affected</strong> releases that are still <strong>supported</strong>. This is called a patch release and increments the patch version by 1 (e.g., 1.2.1). 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).</p>
<p>Which issues are considered critical?</p>
@@ -145,8 +145,6 @@
<p>Whether an issue is considered critical or not is sometimes subjective. In some cases it is obvious and sometimes it is fuzzy. Users should work with committers to figure out the criticality of an issue and get agreement and commitment for support.</p>
-<p>Once an issue is deemed critical, it will be fixed in only those <strong>affected</strong> releases that are still <strong>supported</strong>. This is called a patch release and increments the patch version by 1 (e.g., 1.2.1).</p>
-
<p>Patch releases are normally done <strong>once per month</strong>.</p>
<p>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.</p>