You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by bl...@apache.org on 2022/02/18 09:31:38 UTC
[cassandra-website] branch trunk updated (95bccf5 -> e98ea99)
This is an automated email from the ASF dual-hosted git repository.
blerer pushed a change to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
omit 95bccf5 February 2022 blog "Behind the scenes of an Apache Cassandra Release"
new e98ea99 February 2022 blog "Behind the scenes of an Apache Cassandra Release"
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (95bccf5)
\
N -- N -- N refs/heads/trunk (e98ea99)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
site-content/source/modules/ROOT/pages/blog.adoc | 2 +-
.../pages/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.adoc | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org
[cassandra-website] 01/01: February 2022 blog "Behind the scenes of an Apache Cassandra Release"
Posted by bl...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
blerer pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
commit e98ea999abd4d2eac1179715509fcb7e30210d02
Author: Diogenese Topper <di...@gmail.com>
AuthorDate: Tue Feb 15 12:28:18 2022 -0800
February 2022 blog "Behind the scenes of an Apache Cassandra Release"
patch by Josh McKenzie, Diogenese Topper; review by Erick Ramirez for CASSANDRA-17384
---
...ache-cassandra-release-unsplash-lajos-szabo.jpg | Bin 0 -> 1756830 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 24 +++++++++++
...-the-scenes-of-an-Apache-Cassandra-Release.adoc | 45 +++++++++++++++++++++
3 files changed, 69 insertions(+)
diff --git a/site-content/source/modules/ROOT/images/blog/behind-the-scenes-of-an-apache-cassandra-release-unsplash-lajos-szabo.jpg b/site-content/source/modules/ROOT/images/blog/behind-the-scenes-of-an-apache-cassandra-release-unsplash-lajos-szabo.jpg
new file mode 100644
index 0000000..ebefee2
Binary files /dev/null and b/site-content/source/modules/ROOT/images/blog/behind-the-scenes-of-an-apache-cassandra-release-unsplash-lajos-szabo.jpg differ
diff --git a/site-content/source/modules/ROOT/pages/blog.adoc b/site-content/source/modules/ROOT/pages/blog.adoc
index 2523451..946af0f 100644
--- a/site-content/source/modules/ROOT/pages/blog.adoc
+++ b/site-content/source/modules/ROOT/pages/blog.adoc
@@ -14,6 +14,30 @@ NOTES FOR CONTENT CREATORS
[openblock,card-header]
------
[discrete]
+=== Behind the scenes of an Apache Cassandra Release
+[discrete]
+==== February 18, 2022
+------
+[openblock,card-content]
+------
+Formalizing how we balance the need to evolve and provide cutting-edge features with long-term stability. The simple rules we use to decide when to merge and why we’ll be supporting three GA releases going forward, but why we’ve decided to support four releases for the next cycle.
+
+[openblock,card-btn card-btn--blog]
+--------
+[.btn.btn--alt]
+xref:blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.adoc[Read More]
+--------
+
+------
+----
+//end card
+
+//start card
+[openblock,card shadow relative test]
+----
+[openblock,card-header]
+------
+[discrete]
=== Tightening Security for Apache Cassandra: Part 3
[discrete]
==== February 14, 2022
diff --git a/site-content/source/modules/ROOT/pages/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.adoc b/site-content/source/modules/ROOT/pages/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.adoc
new file mode 100644
index 0000000..37b9497
--- /dev/null
+++ b/site-content/source/modules/ROOT/pages/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.adoc
@@ -0,0 +1,45 @@
+= Behind the scenes of an Apache Cassandra Release
+:page-layout: single-post
+:page-role: blog-post
+:page-post-date: February, 18 2021
+:page-post-author: Josh McKenzie
+:description: The Apache Cassandra Community
+:keywords:
+
+:!figure-caption:
+
+.Image credit: https://unsplash.com/@lou_szabo[Lajos Szabo on Unsplash^]
+image::blog/behind-the-scenes-of-an-apache-cassandra-release-unsplash-lajos-szabo.jpg[Forklift delivering a crate]
+
+== Behind the scenes of an Apache Cassandra Release
+
+When developing a mission-critical piece of infrastructure software used broadly worldwide, it’s critical to have alignment and clarity around modifications to LTS releases. Balancing the need to evolve and provide cutting-edge novel features with providing long-term stability is a challenge we’ve faced for years on the Apache Cassandra project. As the topic came up again on a specific JIRA ticket: https://issues.apache.org/jira/browse/CASSANDRA-16873[CASSANDRA-16873^], we took the oppor [...]
+
+As projects evolve, often tribal knowledge is passed down from developer to developer over the years via IRC or Slack. What we see with maturing, widely adopted software projects, like Apache Cassandra, is that the needs of our users likewise evolve, as does the level of rigor and emphasis on stability required from our releases. Human nature is to understand the rules of a system and then optimize within those bounds based on goals and incentives, so when formalizing our processes we kn [...]
+
+We have formalized our merge heuristics on the following Simple Rules:
+
+* This is a widely used mission-critical database; stability and correctness are table stakes
+* For patch fix releases on a GA branch, prioritize stability (Bug Fix Only)
+* For a Minor release, prioritize introducing new, non-API changing, and non-default behavior breaking features and changes (Bug Fix, Improvements, New Features)
+* Defer disruptive changes (API changes, protocol changes, etc.) to Major releases (All ticket types)
+
+We use Semantic Versioning (https://semver.org/[semver^]) on the project, which leads to releases with the MAJOR.MINOR.PATCH release structure. The Cassandra development community has committed to supporting three GA releases (MAJOR and/or MINOR) at any given time; with an exception being made for 3.0 (see below), the release of a new MINOR or MAJOR will cause the oldest supported GA release to go End of Life.
+
+Here are the three currently supported releases:
+
+* Cassandra 4.0 latest (4.0.2 at this time)
+* Cassandra 3.11 latest (3.11.12 at this time)
+* Cassandra 3.0 latest (3.0.26 at this time)
+
+With the upcoming release of Cassandra 4.1, we are making a one-time exception to our new rules and continuing to support 3.0 as well for one more cycle, so there will be four supported versions for now (3.0.latest, 3.11.latest, 4.0.latest, and 4.1.latest). The reason we’re making this exception is both the longer time window of stabilization that took place on the 3.0 release due to major data structure changes, as well as the long freeze for stabilization leading up to 4.0, which culmi [...]
+
+For the upcoming 4.1 release, we are currently targeting a https://lists.apache.org/thread/lsr45h2n72m8fbz3xqby6lsm7lqr7vm8[freeze in May 2022 and a release in July 2022^], which will put the 4.1 release one year out from 4.0 as committed by the project.
+
+How do we as a project determine when a branch is ready for release? The Apache Foundation provides https://www.apache.org/foundation/voting.html#ReleaseVotes[guidance here^]; Apache projects have a group of contributors called a PMC, or https://www.apache.org/foundation/governance/pmcs[Project Management Committee^], with certain responsibilities to the community and to the project. One of the core responsibilities of the PMC is to verify and vote on new releases for the project. The Ca [...]
+
+This group of contributors takes into account the breadth of features added, the number of bugfixes, architectural modernization, and general needs of the userbase when deciding what is the right cadence and content of a release. On the Cassandra project we are currently targeting yearly Minor or Major releases (depending on whether they’re API breaking or not), with patch releases cut based on either volume of fixes or severity of bugfixes that get committed to the project.
+
+The Open Source model of writing software is unique, and as “software is eating the world,” so “Open Source is eating software.” This model of cross-company, cross-domain, worldwide collaboration has given rise to many of the backbone technologies in use in the world today. I’m proud to be a member of the Apache Cassandra community and look forward to connecting with faces both old and new as we keep marching into the future.
+
+Join us on https://the-asf.slack.com[https://the-asf.slack.com^] in #cassandra or #cassandra-dev, ping the @cassandra-mentors alias in the channel if you need to get situated, xref:community.adoc#discussions[subscribe to the mailing lists^], and come join us! There’s truly never been a better time to get involved with the Cassandra project, and we’re looking forward to continuing to grow into the future.
\ No newline at end of file
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org