[GitHub] [cassandra-website] ErickRamirezAU commented on a change in pull request #100: CASSANDRA-17384: February 2022 blog "Behind the scenes of an Apache Cassandra Release"

[GitBox <gi...@apache.org>]

ErickRamirezAU commented on a change in pull request #100:
URL: https://github.com/apache/cassandra-website/pull/100#discussion_r806689459



##########
File path: site-content/source/modules/ROOT/pages/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.adoc
##########
@@ -0,0 +1,43 @@
+= Behind the scenes of an Apache Cassandra Release
+:page-layout: single-post
+:page-role: blog-post
+:page-post-date: February, 17 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 opportunity to formalize our processes and update our developer documentation in Confluence https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302[here^].
+
+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 knew we were going to need to balance having a user and developer-centric approach with making sure contributors on the project have clear, justified, understandable procedures to adhere to. As an Apache project, https://community.apache.org/committers/decisionMaking.html[building consensus^] is a core part of how we operate and one of our pillars of fostering the long-term health and sustainability of our project.
+
+We have formalized our merge heuristics on the following Simple Rules:

Review comment:
       There needs to be a newline before and after the list items. Otherwise, all the lines render as one really long paragraph instead of a list:
   
   ```suggestion
   We have formalized our merge heuristics on the following Simple Rules:
   
   ```

##########
File path: site-content/source/modules/ROOT/pages/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.adoc
##########
@@ -0,0 +1,43 @@
+= Behind the scenes of an Apache Cassandra Release
+:page-layout: single-post
+:page-role: blog-post
+:page-post-date: February, 17 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 opportunity to formalize our processes and update our developer documentation in Confluence https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302[here^].

Review comment:
       We need to use the permanent wiki URL whenever possible to minimise the occurrences of broken links in the future:
   
   ```suggestion
   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 opportunity to formalize our processes and update our developer documentation in Confluence https://cwiki.apache.org/confluence/x/PpfkCw[here^].
   ```

##########
File path: site-content/source/modules/ROOT/pages/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.adoc
##########
@@ -0,0 +1,43 @@
+= Behind the scenes of an Apache Cassandra Release
+:page-layout: single-post
+:page-role: blog-post
+:page-post-date: February, 17 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 opportunity to formalize our processes and update our developer documentation in Confluence https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302[here^].
+
+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 knew we were going to need to balance having a user and developer-centric approach with making sure contributors on the project have clear, justified, understandable procedures to adhere to. As an Apache project, https://community.apache.org/committers/decisionMaking.html[building consensus^] is a core part of how we operate and one of our pillars of fostering the long-term health and sustainability of our project.
+
+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.

Review comment:
       ```suggestion
   
   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.
   ```




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: pr-unsubscribe@cassandra.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: pr-unsubscribe@cassandra.apache.org
For additional commands, e-mail: pr-help@cassandra.apache.org