RFR: Changes due to stabilization branches [v2]

[Jesper Wilhelmsson]

On Tue, 4 Jun 2024 23:37:25 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates after reviews
>
> src/guide/backporting.md line 20:
> 
>> 18: ## Backporting to a feature release stabilization branch
>> 19: 
>> 20: During ramp down of a feature release there are two branches of the mainline repository in play, the release stabilization branch for the outgoing release, and the master branch where the next release is being developed. Any change going into the release stabilization branch is likely to be desired in the master branch as well. When making a change intended for both the stabilization and the master branches, you should always create your pull request targeting the master branch first, and then, once the pull request is integrated, backport the resulting commit to the release stabilization branch. For bug fixes that are **only** applicable to the release stabilization branch, regular pull requests targeting the stabilization branch should be created.
> 
> I'm wondering if some of these occurrences of "master branch" should be "`master` branch", as "master" is the actual name of the branch.

Agreed. Treating `master` as a name actually makes the flow of the text better as well.

> src/guide/backporting.md line 22:
> 
>> 20: During ramp down of a feature release there are two branches of the mainline repository in play, the release stabilization branch for the outgoing release, and the master branch where the next release is being developed. Any change going into the release stabilization branch is likely to be desired in the master branch as well. When making a change intended for both the stabilization and the master branches, you should always create your pull request targeting the master branch first, and then, once the pull request is integrated, backport the resulting commit to the release stabilization branch. For bug fixes that are **only** applicable to the release stabilization branch, regular pull requests targeting the stabilization branch should be created.
>> 21: 
>> 22: Please note that special rules applies during ramp down regarding what can and can't be included into the ramp down branch. See the [The JDK Release Process] for more information.
> 
> Instead of "ramp down branch", I might use "stabilization branch" as you do in the previous paragraph.

Agreed. Fixed.

> src/guide/the-jdk-release-process.md line 24:
> 
>> 22: 
>> 23: [**The start of a release**]{#release-start}
>> 24: :    Since development is always ongoing in the master branch of the mainline repository ([openjdk/jdk](https://github.com/openjdk/jdk)), the start of a new release can be said to be when the former release is branched out. After the start of the release follows six months of development to implement and integrate all the cool stuff that will go into the next release. After these six months ramp down begins.
> 
> Maybe "branched out" -> "branched for stabilization".

Yep. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/guide/pull/123#discussion_r1626774853
PR Review Comment: https://git.openjdk.org/guide/pull/123#discussion_r1626774799
PR Review Comment: https://git.openjdk.org/guide/pull/123#discussion_r1626774885