releases: add f45 and update status of other releases #111

berrange · 2026-07-14T14:49:10Z

berrange commented

2026-07-14 14:49:10 +00:00

This adds the index, blocking and spins pages for F45, and updates
the status of other releases - marking F44 as a current release
and F42 as EOL, and updating the targets of the various links on
the nav.adoc page.

NB, the F45 pages were a blind cut+paste of the F44 pages, with
only the release number changed.

This adds the index, blocking and spins pages for F45, and updates the status of other releases - marking F44 as a current release and F42 as EOL, and updating the targets of the various links on the nav.adoc page. NB, the F45 pages were a blind cut+paste of the F44 pages, with only the release number changed.

berrange added 1 commit

2026-07-14 14:49:10 +00:00

releases: add f45 and update status of other releases 6687515646

This adds the index, blocking and spins pages for F45, and updates
the status of other releases - marking F44 as a current release
and F42 as EOL, and updating the targets of the various links on
the nav.adoc page.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

jflory7 requested changes

2026-07-14 19:14:46 +00:00

Dismissed

jflory7 left a comment

Hi @berrange, thanks for working on this! 🎉 From a Fedora Docs perspective, the changes seem right but I'd like to ask you to format the new pages under the One Sentence Per Line convention we generally use in Fedora Docs sites. I figure you probably just forked the previous page and it was already like this, but it would be good to get that fixed up in the new pages.

Also, it is @amoloney who can review for a closer look at the content and whether anything looks off.

Hi @berrange, thanks for working on this! 🎉 From a Fedora Docs perspective, the changes seem right but I'd like to ask you to format the new pages under the One Sentence Per Line convention we generally use in Fedora Docs sites. I figure you probably just forked the previous page and it was already like this, but it would be good to get that fixed up in the new pages. Also, it is @amoloney who can review for a closer look at the content and whether anything looks off.

releases/modules/ROOT/pages/f45/blocking.adoc Outdated

					
				@ -0,0 +4,4 @@

				This is the list of release-blocking deliverables.

				The goal is to provide single point of information for Fedora QA,

				Release Engineering

				and other teams.

Please follow the One Sentence Per Line convention. This makes git diffs significantly easier to review in platforms like Forgejo or GitHub.

From the documentation linked above:

Don’t wrap text at a fixed column width. Instead, put each sentence on its own line, a technique called sentence per line. This technique is similar to how you write and organize source code. The result can be spectacular.

Here are some of the advantages of using the sentence per line style:

It prevents reflows (meaning a change early in the paragraph won’t cause the remaining lines in the paragraph to reposition).

You can easily swap sentences.

You can easily separate or join paragraphs.

You can comment out sentences or add commentary to them.

You can spot sentences which are too long or sentences that vary widely in length.

You can spot redundant (and thus mundane) patterns in your writing.

We picked up this idea from the writing guide in the Neo4j documentation. However, it seems like the idea dates back a discovery by Buckminster Fuller in the 1930s, who called it ventilated prose. The technique was also recommended in 2009 by Brandon Rhodes in a blog post about Semantic Linefeeds.

It’s important to note that this technique works because AsciiDoc doesn’t treat wrapped lines in prose as hard line breaks. At least, it doesn’t show up that way to the reader. The line breaks between contiguous lines of prose will not be visible in the rendered document (i.e., as the reader sees it).

NOTE: While a single line break doesn’t appear in the output, two consecutive line breaks starts a new paragraph (or other block).

Please follow the [One Sentence Per Line convention](https://asciidoctor.org/docs/asciidoc-recommended-practices/#one-sentence-per-line). This makes git diffs significantly easier to review in platforms like Forgejo or GitHub. From the documentation linked above: > Don’t wrap text at a fixed column width. Instead, put each sentence on its own line, a technique called sentence per line. This technique is similar to how you write and organize source code. The result can be spectacular. > > Here are some of the advantages of using the sentence per line style: > > * It prevents reflows (meaning a change early in the paragraph won’t cause the remaining lines in the paragraph to reposition). > * You can easily swap sentences. > * You can easily separate or join paragraphs. > * You can comment out sentences or add commentary to them. > * You can spot sentences which are too long or sentences that vary widely in length. > * You can spot redundant (and thus mundane) patterns in your writing. > > We picked up this idea from the writing guide in the [Neo4j documentation](https://neo4j.com/docs/2.2.8/community-docs.html#_writing). However, it seems like the idea dates back a discovery by Buckminster Fuller in the 1930s, who called it [ventilated prose](https://vanemden.wordpress.com/2009/01/01/ventilated-prose/). The technique was also recommended in 2009 by Brandon Rhodes in a blog post about [Semantic Linefeeds](https://rhodesmill.org/brandon/2012/one-sentence-per-line/). > > It’s important to note that this technique works because AsciiDoc doesn’t treat wrapped lines in prose as hard line breaks. At least, it doesn’t show up that way to the reader. The line breaks between contiguous lines of prose will not be visible in the rendered document (i.e., as the reader sees it). > > NOTE: While a single line break doesn’t appear in the output, two consecutive line breaks starts a new paragraph (or other block).

berrange marked this conversation as resolved

releases/modules/ROOT/pages/f45/spins.adoc Outdated

					
				@ -0,0 +4,4 @@

				This page lists Spins (and Labs) that will be produced for Fedora Linux {release-version}.

				NOTE: If the maximum size for a spin needs to be updated,

				file an issue against https://pagure.io/fedora-qa/relval/issues[relval].

Please follow the One Sentence Per Line convention. This makes git diffs significantly easier to review in platforms like Forgejo or GitHub.

From the documentation linked above:

Don’t wrap text at a fixed column width. Instead, put each sentence on its own line, a technique called sentence per line. This technique is similar to how you write and organize source code. The result can be spectacular.

Here are some of the advantages of using the sentence per line style:

It prevents reflows (meaning a change early in the paragraph won’t cause the remaining lines in the paragraph to reposition).

You can easily swap sentences.

You can easily separate or join paragraphs.

You can comment out sentences or add commentary to them.

You can spot sentences which are too long or sentences that vary widely in length.

You can spot redundant (and thus mundane) patterns in your writing.

We picked up this idea from the writing guide in the Neo4j documentation. However, it seems like the idea dates back a discovery by Buckminster Fuller in the 1930s, who called it ventilated prose. The technique was also recommended in 2009 by Brandon Rhodes in a blog post about Semantic Linefeeds.

It’s important to note that this technique works because AsciiDoc doesn’t treat wrapped lines in prose as hard line breaks. At least, it doesn’t show up that way to the reader. The line breaks between contiguous lines of prose will not be visible in the rendered document (i.e., as the reader sees it).

NOTE: While a single line break doesn’t appear in the output, two consecutive line breaks starts a new paragraph (or other block).

Please follow the [One Sentence Per Line convention](https://asciidoctor.org/docs/asciidoc-recommended-practices/#one-sentence-per-line). This makes git diffs significantly easier to review in platforms like Forgejo or GitHub. From the documentation linked above: > Don’t wrap text at a fixed column width. Instead, put each sentence on its own line, a technique called sentence per line. This technique is similar to how you write and organize source code. The result can be spectacular. > > Here are some of the advantages of using the sentence per line style: > > * It prevents reflows (meaning a change early in the paragraph won’t cause the remaining lines in the paragraph to reposition). > * You can easily swap sentences. > * You can easily separate or join paragraphs. > * You can comment out sentences or add commentary to them. > * You can spot sentences which are too long or sentences that vary widely in length. > * You can spot redundant (and thus mundane) patterns in your writing. > > We picked up this idea from the writing guide in the [Neo4j documentation](https://neo4j.com/docs/2.2.8/community-docs.html#_writing). However, it seems like the idea dates back a discovery by Buckminster Fuller in the 1930s, who called it [ventilated prose](https://vanemden.wordpress.com/2009/01/01/ventilated-prose/). The technique was also recommended in 2009 by Brandon Rhodes in a blog post about [Semantic Linefeeds](https://rhodesmill.org/brandon/2012/one-sentence-per-line/). > > It’s important to note that this technique works because AsciiDoc doesn’t treat wrapped lines in prose as hard line breaks. At least, it doesn’t show up that way to the reader. The line breaks between contiguous lines of prose will not be visible in the rendered document (i.e., as the reader sees it). > > NOTE: While a single line break doesn’t appear in the output, two consecutive line breaks starts a new paragraph (or other block).

berrange marked this conversation as resolved

amoloney was assigned by jflory7

2026-07-14 19:15:00 +00:00

berrange force-pushed update-releases from 6687515646 to 6b555595cb

2026-07-15 08:38:33 +00:00

Compare

berrange commented

2026-07-15 08:39:09 +00:00

Updated to follow the one-sentence-per-line style

❤️ 1

berrange referenced this pull request

2026-07-15 08:46:42 +00:00

Fix missing period at end of sentence and comply with one sentence per line convention #112

berrange commented

2026-07-15 08:47:13 +00:00

I figure you probably just forked the previous page and it was already like this, but it would be good to get that fixed up in the new pages.

I submitted a separate MR to fixup existing pages too #112

> I figure you probably just forked the previous page and it was already like this, but it would be good to get that fixed up in the new pages. I submitted a separate MR to fixup existing pages too https://forge.fedoraproject.org/operations/docs/pulls/112

❤️ 1

amoloney merged commit 6b555595cb into main

2026-07-15 13:37:37 +00:00

jflory7 approved these changes

2026-07-16 03:18:29 +00:00

jflory7 left a comment

Thanks @berrange, you rock! 🚀

Sign in to join this conversation.

No reviewers

No labels

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

operations/docs!111

Rows
Columns