kennknowles commented on code in PR #28619:
URL: https://github.com/apache/beam/pull/28619#discussion_r1334730757
##########
contributor-docs/release-guide.md:
##########
@@ -17,44 +14,49 @@ limitations under the License.
# Apache Beam Release Guide
-{{< toc >}}
-
## Introduction
-The Apache Beam project periodically declares and publishes releases.
-A release is one or more packages of the project artifact(s) that are approved
for general public distribution and use.
-They may come with various degrees of caveat regarding their perceived quality
and potential for change, such as “alpha”, “beta”, “incubating”, “stable”, etc.
+The Apache Beam project periodically declares and publishes releases. A
+release is one or more packages of the project artifact(s) that are approved
+for general public distribution and use. They may come with various degrees of
+caveat regarding their perceived quality and potential for change, such as
+“alpha”, “beta”, “incubating”, “stable”, etc.
-The Beam community treats releases with great importance.
-They are a public face of the project and most users interact with the project
only through the releases. Releases are signed off by the entire Beam community
in a public vote.
+The Beam community treats releases with great importance. They are a public
+face of the project and most users interact with the project only through the
+releases. Releases are signed off by the entire Beam community in a public
+vote.
-Each release is executed by a *Release Manager*, who is selected among the
Beam committers.
-This document describes the process that the Release Manager follows to
perform a release.
-Any changes to this process should be discussed and adopted on the [dev@
mailing list](/get-started/support/).
+Each release is executed by a *Release Manager*, who is selected among the Beam
+committers. This document describes the process that the Release Manager
+follows to perform a release. Any changes to this process should be discussed
+and adopted on the [dev@ mailing list](/get-started/support/).
-Please remember that publishing software has legal consequences.
-This guide complements the foundation-wide [Product Release
Policy](https://www.apache.org/dev/release.html) and [Release Distribution
Policy](https://www.apache.org/dev/release-distribution).
+Please remember that publishing software has legal consequences. This guide
+complements the foundation-wide [Product Release
+Policy](https://www.apache.org/dev/release.html) and [Release Distribution
+Policy](https://www.apache.org/dev/release-distribution).
### Overview
-<img src="/images/release-guide-1.png" alt="Release step flow chart"
width="100%">
+<img src="images/release-guide-1.png" alt="Release step flow chart"
width="100%">
The release process consists of several steps:
1. Decide to release
-1. Prepare for the release
-1. Build a release candidate
- 1. Create a release branch
- 1. Verify release branch
- 1. Tag a release candidate
- 1. Build release artifacts
-1. Vote on the release candidate
- * During vote process, run validation tests
-1. If necessary, fix any issues and go back to step 3.
-1. Finalize the release
-1. Promote the release
-
-**********
+2. Prepare for the release
+3. Build a release candidate
+ 1. Create a release branch
+ 2. Verify release branch
+ 3. Tag a release candidate
+ 4. Build release artifacts
+4. Vote on the release candidate
+ * During vote process, run validation tests
+5. If necessary, fix any issues and go back to step 3.
+6. Finalize the release
+7. Promote the release
Review Comment:
Random aside:
The guideline for when to use a numbered list vs bullets in writing is
whether or not the order of the items matters. But in the case of programmers
applying their "source/render/diff" brain to markdown they've invented a third
category which might be useful if it really came into being as a thing in
writing: a kind of bullet that indicates that the order matters, but that order
is to be the textual order which was there all along. I'll say that I think ↳
is probably a nice symbol that communicates that intent more elegantly.
So, yea, I have maybe thought too much about this, because I care about
writing and reading and language. I think the actual thing that has been
created it way more interesting than its creators intended :-)
##########
contributor-docs/release-guide.md:
##########
@@ -17,44 +14,49 @@ limitations under the License.
# Apache Beam Release Guide
-{{< toc >}}
-
## Introduction
-The Apache Beam project periodically declares and publishes releases.
-A release is one or more packages of the project artifact(s) that are approved
for general public distribution and use.
-They may come with various degrees of caveat regarding their perceived quality
and potential for change, such as “alpha”, “beta”, “incubating”, “stable”, etc.
+The Apache Beam project periodically declares and publishes releases. A
+release is one or more packages of the project artifact(s) that are approved
+for general public distribution and use. They may come with various degrees of
+caveat regarding their perceived quality and potential for change, such as
+“alpha”, “beta”, “incubating”, “stable”, etc.
-The Beam community treats releases with great importance.
-They are a public face of the project and most users interact with the project
only through the releases. Releases are signed off by the entire Beam community
in a public vote.
+The Beam community treats releases with great importance. They are a public
+face of the project and most users interact with the project only through the
+releases. Releases are signed off by the entire Beam community in a public
+vote.
-Each release is executed by a *Release Manager*, who is selected among the
Beam committers.
-This document describes the process that the Release Manager follows to
perform a release.
-Any changes to this process should be discussed and adopted on the [dev@
mailing list](/get-started/support/).
+Each release is executed by a *Release Manager*, who is selected among the Beam
+committers. This document describes the process that the Release Manager
+follows to perform a release. Any changes to this process should be discussed
+and adopted on the [dev@ mailing list](/get-started/support/).
-Please remember that publishing software has legal consequences.
-This guide complements the foundation-wide [Product Release
Policy](https://www.apache.org/dev/release.html) and [Release Distribution
Policy](https://www.apache.org/dev/release-distribution).
+Please remember that publishing software has legal consequences. This guide
+complements the foundation-wide [Product Release
+Policy](https://www.apache.org/dev/release.html) and [Release Distribution
+Policy](https://www.apache.org/dev/release-distribution).
### Overview
-<img src="/images/release-guide-1.png" alt="Release step flow chart"
width="100%">
+<img src="images/release-guide-1.png" alt="Release step flow chart"
width="100%">
The release process consists of several steps:
1. Decide to release
-1. Prepare for the release
-1. Build a release candidate
- 1. Create a release branch
- 1. Verify release branch
- 1. Tag a release candidate
- 1. Build release artifacts
-1. Vote on the release candidate
- * During vote process, run validation tests
-1. If necessary, fix any issues and go back to step 3.
-1. Finalize the release
-1. Promote the release
-
-**********
+2. Prepare for the release
+3. Build a release candidate
+ 1. Create a release branch
+ 2. Verify release branch
+ 3. Tag a release candidate
+ 4. Build release artifacts
+4. Vote on the release candidate
+ * During vote process, run validation tests
+5. If necessary, fix any issues and go back to step 3.
+6. Finalize the release
+7. Promote the release
Review Comment:
Random aside:
The guideline for when to use a numbered list vs bullets in writing is
whether or not the order of the items matters. But in the case of programmers
applying their "source/render/diff" brain to markdown they've invented a third
category which might be useful if it really came into being as a thing in
writing: a kind of bullet that indicates that the order matters, but that order
is to be the textual order which was there all along. I'll say that I think ↳
is probably a nice symbol that communicates that intent more elegantly.
So, yea, I have maybe thought too much about this, because I care about
writing and reading and language. I think the actual thing that has been
created it way more interesting than its creators intended :-)
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
