[PATCH] Documentation/process/: Change 5.x to 6.x; clarify terms; added note.

[PATCH] Documentation/process/: Change 5.x to 6.x; clarify terms; added note.

[Dante Strock]

From 1fbe3d56d604a0f8a87ed1d3f092b84c2fab4392 Mon Sep 17 00:00:00 2001
From: Dante Strock <dantestrock@hotmail.com>
Date: Sat, 7 Jun 2025 09:29:36 +0100
Subject: [PATCH] Documentation/process/: Change 5.x to 6.x; clarify
 terms; added note.

From: Dante Strock <dantestrock@hotmail.com>

As a possible suggestion, might it be worthwhile adding a terminology
section specific to each section of the kernel documentation? That way
developers have a handy reference to refer back to for terms they might
not understand.

---

Documentation/process/2.Process.rst:

- Changed some instances of 5.x to 6.x(though kept some instances of 5.x
that are used in examples).
- Clarified the term "rc" in brackets.
- Added a notice for people installing Git or Mercurial to check their
distribution repository for the latest version of the software.

Signed-off-by: Dante Strock <dantestrock@hotmail.com>
---
 Documentation/process/2.Process.rst | 26 +++++++++++++++-----------
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
index ef3b116492df..70f8a6603454 100644
--- a/Documentation/process/2.Process.rst
+++ b/Documentation/process/2.Process.rst
@@ -18,17 +18,17 @@ major kernel release happening every two or three months.  The recent
 release history looks like this:
 
 	======  =================
-	5.0	March 3, 2019
-	5.1	May 5, 2019
-	5.2	July 7, 2019
-	5.3	September 15, 2019
-	5.4	November 24, 2019
-	5.5	January 6, 2020
+	6.10	July 14, 2024
+	6.11	September 15, 2024
+	6.12	November 17, 2024
+	6.13	January 20, 2025
+	6.14	March 24, 2025
+	6.15	May 25, 2025
 	======  =================
 
-Every 5.x release is a major kernel release with new features, internal
+Every 6.x release is a major kernel release with new features, internal
 API changes, and more.  A typical release can contain about 13,000
-changesets with changes to several hundred thousand lines of code.  5.x is
+changesets with changes to several hundred thousand lines of code.  6.x is
 the leading edge of Linux kernel development; the kernel uses a
 rolling development model which is continually integrating major changes.
 
@@ -48,9 +48,9 @@ detail later on).
 
 The merge window lasts for approximately two weeks.  At the end of this
 time, Linus Torvalds will declare that the window is closed and release the
-first of the "rc" kernels.  For the kernel which is destined to be 5.6,
+first of the "rc"("release candidate") kernels.  For the kernel which is destined to be 6.16,
 for example, the release which happens at the end of the merge window will
-be called 5.6-rc1.  The -rc1 release is the signal that the time to
+be called 6.16-rc1.  The -rc1 release is the signal that the time to
 merge new features has passed, and that the time to stabilize the next
 kernel has begun.
 
@@ -99,7 +99,7 @@ release is made.  In the real world, this kind of perfection is hard to
 achieve; there are just too many variables in a project of this size.
 There comes a point where delaying the final release just makes the problem
 worse; the pile of changes waiting for the next merge window will grow
-larger, creating even more regressions the next time around.  So most 5.x
+larger, creating even more regressions the next time around.  So most 6.x
 kernels go out with a handful of known regressions though, hopefully, none
 of them are serious.
 
@@ -381,6 +381,10 @@ Some major subsystem maintainers use quilt to manage patches intended to go
 upstream.  For the management of certain kinds of trees (-mm, for example),
 quilt is the best tool for the job.
 
+Note that not all Linux distributions have the latest version of Git
+or Mercurial available in their repositories. Consult the package
+maintainer for your distribution to get the package updated or
+download it directly from the website.
-- 
2.43.0

Re: [PATCH] Documentation/process/: Change 5.x to 6.x; clarify terms; added note.

[Jonathan Corbet]

Thanks for working to improve our documentation!

Naturally, I have some comments, the first of which being to run
scripts/get_maintainer.pl on your patches to get the list of people you
should send them to.  Then cut-and-paste it rather then typoing it by
hand :)

Dante Strock <dantestrock@hotmail.com> writes:

> From 1fbe3d56d604a0f8a87ed1d3f092b84c2fab4392 Mon Sep 17 00:00:00 2001
> From: Dante Strock <dantestrock@hotmail.com>
> Date: Sat, 7 Jun 2025 09:29:36 +0100
> Subject: [PATCH] Documentation/process/: Change 5.x to 6.x; clarify
>  terms; added note.
>
> From: Dante Strock <dantestrock@hotmail.com>
>
> As a possible suggestion, might it be worthwhile adding a terminology
> section specific to each section of the kernel documentation? That way
> developers have a handy reference to refer back to for terms they might
> not understand.
>
> ---
>
> Documentation/process/2.Process.rst:
>
> - Changed some instances of 5.x to 6.x(though kept some instances of 5.x
> that are used in examples).
> - Clarified the term "rc" in brackets.
> - Added a notice for people installing Git or Mercurial to check their
> distribution repository for the latest version of the software.
>
> Signed-off-by: Dante Strock <dantestrock@hotmail.com>
> ---
>  Documentation/process/2.Process.rst | 26 +++++++++++++++-----------
>  1 file changed, 15 insertions(+), 11 deletions(-)

This is backward - the changelog goes above the "---" line, any
additional comments go below.

A bulleted list like the above is a good sign that the patch should be
split up - patches should do one thing.

> diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
> index ef3b116492df..70f8a6603454 100644
> --- a/Documentation/process/2.Process.rst
> +++ b/Documentation/process/2.Process.rst
> @@ -18,17 +18,17 @@ major kernel release happening every two or three months.  The recent
>  release history looks like this:
>  
>  	======  =================
> -	5.0	March 3, 2019
> -	5.1	May 5, 2019
> -	5.2	July 7, 2019
> -	5.3	September 15, 2019
> -	5.4	November 24, 2019
> -	5.5	January 6, 2020
> +	6.10	July 14, 2024
> +	6.11	September 15, 2024
> +	6.12	November 17, 2024
> +	6.13	January 20, 2025
> +	6.14	March 24, 2025
> +	6.15	May 25, 2025
>  	======  =================
>  
> -Every 5.x release is a major kernel release with new features, internal
> +Every 6.x release is a major kernel release with new features, internal
>  API changes, and more.  A typical release can contain about 13,000
> -changesets with changes to several hundred thousand lines of code.  5.x is
> +changesets with changes to several hundred thousand lines of code.  6.x is
>  the leading edge of Linux kernel development; the kernel uses a
>  rolling development model which is continually integrating major changes.

I do not object to these change and could apply this, but it might be
nice at some point to rephrase this stuff so that we don't end up doing
these updates repeatedly.  After all, we'll be at 7.x within a year...  

> @@ -48,9 +48,9 @@ detail later on).
>  
>  The merge window lasts for approximately two weeks.  At the end of this
>  time, Linus Torvalds will declare that the window is closed and release the
> -first of the "rc" kernels.  For the kernel which is destined to be 5.6,
> +first of the "rc"("release candidate") kernels.  For the kernel which is destined to be 6.16,

This is a separate change.  But, of course, yesterday's 6.16-rc1 is in
no way a "release candidate".  It's really just the naming scheme that
Linus uses for his testing releases, calling them "release candidates"
muddies the water and risks reigniting old debates.

> +Note that not all Linux distributions have the latest version of Git
> +or Mercurial available in their repositories. Consult the package
> +maintainer for your distribution to get the package updated or
> +download it directly from the website.

I almost wonder if the references to Mercurial shouldn't just come out;
I am not aware of anybody using it for kernel work at this point.

I'm also not aware of anybody who has run into trouble because their
distribution lacked a shiny new version of Git.  I'm not sure we want to
encourage people to bug their distributors to accelerate updates?  Is
this paragraph solving a specific problem that you have encountered?

Thanks,

jon

Re: [PATCH] Documentation/process/: Change 5.x to 6.x; clarify terms; added note.

[Dante Strock]

    Thanks for working to improve our documentation! Naturally, I have
    some comments, the first of which being to run
    scripts/get_maintainer.pl on your patches to get the list of people
    you should send them to. Then cut-and-paste it rather then typoing
    it by hand :) Dante Strock <dantestrock@hotmail.com> writes:

         From 1fbe3d56d604a0f8a87ed1d3f092b84c2fab4392 Mon Sep 17
        00:00:00 2001 From: Dante Strock <dantestrock@hotmail.com> Date:
        Sat, 7 Jun 2025 09:29:36 +0100 Subject: [PATCH]
        Documentation/process/: Change 5.x to 6.x; clarify terms; added
        note. From: Dante Strock <dantestrock@hotmail.com> As a possible
        suggestion, might it be worthwhile adding a terminology section
        specific to each section of the kernel documentation? That way
        developers have a handy reference to refer back to for terms
        they might not understand. ---
        Documentation/process/2.Process.rst: - Changed some instances of
        5.x to 6.x(though kept some instances of 5.x that are used in
        examples). - Clarified the term "rc" in brackets. - Added a
        notice for people installing Git or Mercurial to check their
        distribution repository for the latest version of the software.
        Signed-off-by: Dante Strock <dantestrock@hotmail.com> ---
        Documentation/process/2.Process.rst | 26
        +++++++++++++++----------- 1 file changed, 15 insertions(+), 11
        deletions(-)

    This is backward - the changelog goes above the "---" line, any
    additional comments go below. A bulleted list like the above is a
    good sign that the patch should be split up - patches should do one
    thing.

        diff --git a/Documentation/process/2.Process.rst
        b/Documentation/process/2.Process.rst index
        ef3b116492df..70f8a6603454 100644 ---
        a/Documentation/process/2.Process.rst +++
        b/Documentation/process/2.Process.rst @@ -18,17 +18,17 @@ major
        kernel release happening every two or three months. The recent
        release history looks like this: ====== ================= - 5.0
        March 3, 2019 - 5.1 May 5, 2019 - 5.2 July 7, 2019 - 5.3
        September 15, 2019 - 5.4 November 24, 2019 - 5.5 January 6, 2020
        + 6.10 July 14, 2024 + 6.11 September 15, 2024 + 6.12 November
        17, 2024 + 6.13 January 20, 2025 + 6.14 March 24, 2025 + 6.15
        May 25, 2025 ====== ================= -Every 5.x release is a
        major kernel release with new features, internal +Every 6.x
        release is a major kernel release with new features, internal
        API changes, and more. A typical release can contain about
        13,000 -changesets with changes to several hundred thousand
        lines of code. 5.x is +changesets with changes to several
        hundred thousand lines of code. 6.x is the leading edge of Linux
        kernel development; the kernel uses a rolling development model
        which is continually integrating major changes.

    I do not object to these change and could apply this, but it might
    be nice at some point to rephrase this stuff so that we don't end up
    doing these updates repeatedly. After all, we'll be at 7.x within a
    year...

        @@ -48,9 +48,9 @@ detail later on). The merge window lasts for
        approximately two weeks. At the end of this time, Linus Torvalds
        will declare that the window is closed and release the -first of
        the "rc" kernels. For the kernel which is destined to be 5.6,
        +first of the "rc"("release candidate") kernels. For the kernel
        which is destined to be 6.16,

    This is a separate change. But, of course, yesterday's 6.16-rc1 is
    in no way a "release candidate". It's really just the naming scheme
    that Linus uses for his testing releases, calling them "release
    candidates" muddies the water and risks reigniting old debates.

        +Note that not all Linux distributions have the latest version
        of Git +or Mercurial available in their repositories. Consult
        the package +maintainer for your distribution to get the package
        updated or +download it directly from the website.

    I almost wonder if the references to Mercurial shouldn't just come
    out; I am not aware of anybody using it for kernel work at this
    point. I'm also not aware of anybody who has run into trouble
    because their distribution lacked a shiny new version of Git. I'm
    not sure we want to encourage people to bug their distributors to
    accelerate updates? Is this paragraph solving a specific problem
    that you have encountered? Thanks, jon

Hello,


Apologies about the sending of the original email: I had been doing a 
lot of fiddling that morning to get things setup and by the time I sent 
the email, had failed to check the address before sending. I'll keep 
this in mind for next time and will be more diligent. Thank you as well 
for the feedback on my changes. I've taken note of these for future 
reference.

I agree with you on the first point you make about the release numbers. 
I suppose we could remove the example version history entirely so as to 
avoid updating version numbers constantly, or stick with one version 
number(e.g. 6.0, 6.1, 6.2, 6.3, etc.) as an example and keep it that 
way. I thought it would've been good to update it to keep the page 
fresh(as the versions listed were between 2019-2020; we're now in 2025), 
but I can see the point you're making and a rephrase might be better so 
as to avoid constantly changing it.

I've always read and understood "rc" to mean "release candidate" and 
thought it would be good, as a general principle, to clarify what 
abbreviated terms like "rc" meant. If this creates the risk of confusion 
and unnecessary debate, then do not include it. This is partly the 
reason why I suggested a terminology section specific to each section of 
the documentation that could help clarify technical or abbreviated terms 
that readers might not have encountered before. In this case, "rc" is 
not that much of a deal to warrant a place in a terminology section, but 
in other sections of the documentation which can get very technical, it 
may well be worth it.

I see very little mention online of Mercurial either: Git seems to be 
the standard VCS nowadays. It might be wise to simply point people to 
Git only, that way everybody uses the same tools and it streamlines 
development for the whole kernel. As for keeping the software 
up-to-date: I put it in as I've found a lot of mentions online of 
packages in some distribution repos being outdated, though with software 
like Git that is heavily used, this really shouldn't be an issue, but I 
thought it still to be worth noting just in case.

Hope this explains my patch well enough.

Thanks,

Dante

Re: [PATCH] Documentation/process/: Change 5.x to 6.x; clarify terms; added note.

[Randy Dunlap]

On 6/9/25 7:37 AM, Jonathan Corbet wrote:
> I almost wonder if the references to Mercurial shouldn't just come out;
> I am not aware of anybody using it for kernel work at this point.

Ack that. +1

-- 
~Randy

Re: [PATCH] Documentation/process/: Change 5.x to 6.x; clarify terms; added note.

[Randy Dunlap]

On 6/9/25 12:17 PM, Dante Strock wrote:

[snip]

>        diff --git a/Documentation/process/2.Process.rst
>        b/Documentation/process/2.Process.rst index
>        ef3b116492df..70f8a6603454 100644 ---
>        a/Documentation/process/2.Process.rst +++
>        b/Documentation/process/2.Process.rst @@ -18,17 +18,17 @@ major
>        kernel release happening every two or three months. The recent
>        release history looks like this: ====== ================= - 5.0
>        March 3, 2019 - 5.1 May 5, 2019 - 5.2 July 7, 2019 - 5.3
>        September 15, 2019 - 5.4 November 24, 2019 - 5.5 January 6, 2020
>        + 6.10 July 14, 2024 + 6.11 September 15, 2024 + 6.12 November
>        17, 2024 + 6.13 January 20, 2025 + 6.14 March 24, 2025 + 6.15
>        May 25, 2025 ====== ================= -Every 5.x release is a
>        major kernel release with new features, internal +Every 6.x
>        release is a major kernel release with new features, internal
>        API changes, and more. A typical release can contain about
>        13,000 -changesets with changes to several hundred thousand
>        lines of code. 5.x is +changesets with changes to several
>        hundred thousand lines of code. 6.x is the leading edge of Linux
>        kernel development; the kernel uses a rolling development model
>        which is continually integrating major changes.
> 
>    I do not object to these change and could apply this, but it might
>    be nice at some point to rephrase this stuff so that we don't end up
>    doing these updates repeatedly. After all, we'll be at 7.x within a
>    year...

+1

>        @@ -48,9 +48,9 @@ detail later on). The merge window lasts for
>        approximately two weeks. At the end of this time, Linus Torvalds
>        will declare that the window is closed and release the -first of
>        the "rc" kernels. For the kernel which is destined to be 5.6,
>        +first of the "rc"("release candidate") kernels. For the kernel
>        which is destined to be 6.16,
> 
>    This is a separate change. But, of course, yesterday's 6.16-rc1 is
>    in no way a "release candidate". It's really just the naming scheme
>    that Linus uses for his testing releases, calling them "release
>    candidates" muddies the water and risks reigniting old debates.

I have also thought of -rc as "release candidate", but -rc[1234] are
"early release candidates" to my brain. Or the could be called -nc[1234]
as in "non-candidates."

> 
>        +Note that not all Linux distributions have the latest version
>        of Git +or Mercurial available in their repositories. Consult
>        the package +maintainer for your distribution to get the package
>        updated or +download it directly from the website.
> 
[snip]

> 
> Hello,
> 

Parts of this email style guide might be helpful in the future:
  https://people.kernel.org/tglx/notes-about-netiquette

[snip]

Thanks.
-- 
~Randy

Re: [PATCH] Documentation/process/: Change 5.x to 6.x; clarify terms; added note.

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 5900 bytes --]

On Mon, Jun 09, 2025 at 08:37:05AM -0600, Jonathan Corbet wrote:
> Dante Strock <dantestrock@hotmail.com> writes:
> 
> > diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
> > index ef3b116492df..70f8a6603454 100644
> > --- a/Documentation/process/2.Process.rst
> > +++ b/Documentation/process/2.Process.rst
> > @@ -18,17 +18,17 @@ major kernel release happening every two or three months.  The recent
> >  release history looks like this:
> >  
> >  	======  =================
> > -	5.0	March 3, 2019
> > -	5.1	May 5, 2019
> > -	5.2	July 7, 2019
> > -	5.3	September 15, 2019
> > -	5.4	November 24, 2019
> > -	5.5	January 6, 2020
> > +	6.10	July 14, 2024
> > +	6.11	September 15, 2024
> > +	6.12	November 17, 2024
> > +	6.13	January 20, 2025
> > +	6.14	March 24, 2025
> > +	6.15	May 25, 2025
> >  	======  =================
> >  
> > -Every 5.x release is a major kernel release with new features, internal
> > +Every 6.x release is a major kernel release with new features, internal
> >  API changes, and more.  A typical release can contain about 13,000
> > -changesets with changes to several hundred thousand lines of code.  5.x is
> > +changesets with changes to several hundred thousand lines of code.  6.x is
> >  the leading edge of Linux kernel development; the kernel uses a
> >  rolling development model which is continually integrating major changes.
> 
> I do not object to these change and could apply this, but it might be
> nice at some point to rephrase this stuff so that we don't end up doing
> these updates repeatedly.  After all, we'll be at 7.x within a year...  

What about not hard-coding first version number component like below?

---- >8 ----
diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
index ef3b116492df08..47bcc6248a1338 100644
--- a/Documentation/process/2.Process.rst
+++ b/Documentation/process/2.Process.rst
@@ -13,24 +13,12 @@ how the process works is required in order to be an effective part of it.
 The big picture
 ---------------
 
-The kernel developers use a loosely time-based release process, with a new
-major kernel release happening every two or three months.  The recent
-release history looks like this:
-
-	======  =================
-	5.0	March 3, 2019
-	5.1	May 5, 2019
-	5.2	July 7, 2019
-	5.3	September 15, 2019
-	5.4	November 24, 2019
-	5.5	January 6, 2020
-	======  =================
-
-Every 5.x release is a major kernel release with new features, internal
-API changes, and more.  A typical release can contain about 13,000
-changesets with changes to several hundred thousand lines of code.  5.x is
-the leading edge of Linux kernel development; the kernel uses a
-rolling development model which is continually integrating major changes.
+The kernel developers use a loosely time-based, rolling release development
+process. A new major kernel release (a.x) happens every two or three months,
+which comes with new features, internal API changes, and more. A typical
+release can contain about 13,000 changesets with changes to several hundred
+thousand lines of code. Recent releases, along with their dates, can be found
+at `Linux Kernel Newbies site <https://kernelnewbies.org/LinuxVersions>`_.
 
 A relatively straightforward discipline is followed with regard to the
 merging of patches for each release.  At the beginning of each development
@@ -46,13 +34,12 @@ merge window do not come out of thin air; they have been collected, tested,
 and staged ahead of time.  How that process works will be described in
 detail later on).
 
-The merge window lasts for approximately two weeks.  At the end of this
-time, Linus Torvalds will declare that the window is closed and release the
-first of the "rc" kernels.  For the kernel which is destined to be 5.6,
-for example, the release which happens at the end of the merge window will
-be called 5.6-rc1.  The -rc1 release is the signal that the time to
-merge new features has passed, and that the time to stabilize the next
-kernel has begun.
+The merge window lasts for approximately two weeks. At the end of this time,
+Linus Torvalds will declare that the window is closed and release the first of
+the "rc" kernels.  For the kernel which is destined to be a.x, the release
+which happens at the end of the merge window will be called a.x-rc1. That
+release is the signal that the time to merge new features has passed, and that
+the time to stabilize the next kernel has begun.
 
 Over the next six to ten weeks, only patches which fix problems should be
 submitted to the mainline.  On occasion a more significant change will be
@@ -99,13 +86,13 @@ release is made.  In the real world, this kind of perfection is hard to
 achieve; there are just too many variables in a project of this size.
 There comes a point where delaying the final release just makes the problem
 worse; the pile of changes waiting for the next merge window will grow
-larger, creating even more regressions the next time around.  So most 5.x
+larger, creating even more regressions the next time around.  So most
 kernels go out with a handful of known regressions though, hopefully, none
 of them are serious.
 
 Once a stable release is made, its ongoing maintenance is passed off to the
 "stable team," currently Greg Kroah-Hartman. The stable team will release
-occasional updates to the stable release using the 5.x.y numbering scheme.
+occasional updates to the stable release using the a.x.y numbering scheme.
 To be considered for an update release, a patch must (1) fix a significant
 bug, and (2) already be merged into the mainline for the next development
 kernel. Kernels will typically receive stable updates for a little more

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] Documentation/process/: Change 5.x to 6.x; clarify terms; added note.

[Dante Strock]

On 10/06/2025 04:45, Bagas Sanjaya wrote:
> On Mon, Jun 09, 2025 at 08:37:05AM -0600, Jonathan Corbet wrote:
>> Dante Strock <dantestrock@hotmail.com> writes:
>>
>>> diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
>>> index ef3b116492df..70f8a6603454 100644
>>> --- a/Documentation/process/2.Process.rst
>>> +++ b/Documentation/process/2.Process.rst
>>> @@ -18,17 +18,17 @@ major kernel release happening every two or three months.  The recent
>>>   release history looks like this:
>>>   
>>>   	======  =================
>>> -	5.0	March 3, 2019
>>> -	5.1	May 5, 2019
>>> -	5.2	July 7, 2019
>>> -	5.3	September 15, 2019
>>> -	5.4	November 24, 2019
>>> -	5.5	January 6, 2020
>>> +	6.10	July 14, 2024
>>> +	6.11	September 15, 2024
>>> +	6.12	November 17, 2024
>>> +	6.13	January 20, 2025
>>> +	6.14	March 24, 2025
>>> +	6.15	May 25, 2025
>>>   	======  =================
>>>   
>>> -Every 5.x release is a major kernel release with new features, internal
>>> +Every 6.x release is a major kernel release with new features, internal
>>>   API changes, and more.  A typical release can contain about 13,000
>>> -changesets with changes to several hundred thousand lines of code.  5.x is
>>> +changesets with changes to several hundred thousand lines of code.  6.x is
>>>   the leading edge of Linux kernel development; the kernel uses a
>>>   rolling development model which is continually integrating major changes.
>> I do not object to these change and could apply this, but it might be
>> nice at some point to rephrase this stuff so that we don't end up doing
>> these updates repeatedly.  After all, we'll be at 7.x within a year...
> What about not hard-coding first version number component like below?
>
> ---- >8 ----
> diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
> index ef3b116492df08..47bcc6248a1338 100644
> --- a/Documentation/process/2.Process.rst
> +++ b/Documentation/process/2.Process.rst
> @@ -13,24 +13,12 @@ how the process works is required in order to be an effective part of it.
>   The big picture
>   ---------------
>   
> -The kernel developers use a loosely time-based release process, with a new
> -major kernel release happening every two or three months.  The recent
> -release history looks like this:
> -
> -	======  =================
> -	5.0	March 3, 2019
> -	5.1	May 5, 2019
> -	5.2	July 7, 2019
> -	5.3	September 15, 2019
> -	5.4	November 24, 2019
> -	5.5	January 6, 2020
> -	======  =================
> -
> -Every 5.x release is a major kernel release with new features, internal
> -API changes, and more.  A typical release can contain about 13,000
> -changesets with changes to several hundred thousand lines of code.  5.x is
> -the leading edge of Linux kernel development; the kernel uses a
> -rolling development model which is continually integrating major changes.
> +The kernel developers use a loosely time-based, rolling release development
> +process. A new major kernel release (a.x) happens every two or three months,
> +which comes with new features, internal API changes, and more. A typical
> +release can contain about 13,000 changesets with changes to several hundred
> +thousand lines of code. Recent releases, along with their dates, can be found
> +at `Linux Kernel Newbies site <https://kernelnewbies.org/LinuxVersions>`_.
>   
>   A relatively straightforward discipline is followed with regard to the
>   merging of patches for each release.  At the beginning of each development
> @@ -46,13 +34,12 @@ merge window do not come out of thin air; they have been collected, tested,
>   and staged ahead of time.  How that process works will be described in
>   detail later on).
>   
> -The merge window lasts for approximately two weeks.  At the end of this
> -time, Linus Torvalds will declare that the window is closed and release the
> -first of the "rc" kernels.  For the kernel which is destined to be 5.6,
> -for example, the release which happens at the end of the merge window will
> -be called 5.6-rc1.  The -rc1 release is the signal that the time to
> -merge new features has passed, and that the time to stabilize the next
> -kernel has begun.
> +The merge window lasts for approximately two weeks. At the end of this time,
> +Linus Torvalds will declare that the window is closed and release the first of
> +the "rc" kernels.  For the kernel which is destined to be a.x, the release
> +which happens at the end of the merge window will be called a.x-rc1. That
> +release is the signal that the time to merge new features has passed, and that
> +the time to stabilize the next kernel has begun.
>   
>   Over the next six to ten weeks, only patches which fix problems should be
>   submitted to the mainline.  On occasion a more significant change will be
> @@ -99,13 +86,13 @@ release is made.  In the real world, this kind of perfection is hard to
>   achieve; there are just too many variables in a project of this size.
>   There comes a point where delaying the final release just makes the problem
>   worse; the pile of changes waiting for the next merge window will grow
> -larger, creating even more regressions the next time around.  So most 5.x
> +larger, creating even more regressions the next time around.  So most
>   kernels go out with a handful of known regressions though, hopefully, none
>   of them are serious.
>   
>   Once a stable release is made, its ongoing maintenance is passed off to the
>   "stable team," currently Greg Kroah-Hartman. The stable team will release
> -occasional updates to the stable release using the 5.x.y numbering scheme.
> +occasional updates to the stable release using the a.x.y numbering scheme.
>   To be considered for an update release, a patch must (1) fix a significant
>   bug, and (2) already be merged into the mainline for the next development
>   kernel. Kernels will typically receive stable updates for a little more
>
> Thanks.
>
I actually think this works better instead of removing the version 
numbers entirely or updating release numbers every year. Might be worth 
it to look for other pages in the documentation that have hard-coded 
version numbers and changing them also so that the version numbers don't 
need to be updated with every release.


Thanks,
Dante

Re: [PATCH] Documentation/process/: Change 5.x to 6.x; clarify terms; added note.

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 6771 bytes --]

On Tue, Jun 10, 2025 at 07:21:16AM +0100, Dante Strock wrote:
> 
> On 10/06/2025 04:45, Bagas Sanjaya wrote:
> > On Mon, Jun 09, 2025 at 08:37:05AM -0600, Jonathan Corbet wrote:
> > > Dante Strock <dantestrock@hotmail.com> writes:
> > > 
> > > > diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
> > > > index ef3b116492df..70f8a6603454 100644
> > > > --- a/Documentation/process/2.Process.rst
> > > > +++ b/Documentation/process/2.Process.rst
> > > > @@ -18,17 +18,17 @@ major kernel release happening every two or three months.  The recent
> > > >   release history looks like this:
> > > >   	======  =================
> > > > -	5.0	March 3, 2019
> > > > -	5.1	May 5, 2019
> > > > -	5.2	July 7, 2019
> > > > -	5.3	September 15, 2019
> > > > -	5.4	November 24, 2019
> > > > -	5.5	January 6, 2020
> > > > +	6.10	July 14, 2024
> > > > +	6.11	September 15, 2024
> > > > +	6.12	November 17, 2024
> > > > +	6.13	January 20, 2025
> > > > +	6.14	March 24, 2025
> > > > +	6.15	May 25, 2025
> > > >   	======  =================
> > > > -Every 5.x release is a major kernel release with new features, internal
> > > > +Every 6.x release is a major kernel release with new features, internal
> > > >   API changes, and more.  A typical release can contain about 13,000
> > > > -changesets with changes to several hundred thousand lines of code.  5.x is
> > > > +changesets with changes to several hundred thousand lines of code.  6.x is
> > > >   the leading edge of Linux kernel development; the kernel uses a
> > > >   rolling development model which is continually integrating major changes.
> > > I do not object to these change and could apply this, but it might be
> > > nice at some point to rephrase this stuff so that we don't end up doing
> > > these updates repeatedly.  After all, we'll be at 7.x within a year...
> > What about not hard-coding first version number component like below?
> > 
> > ---- >8 ----
> > diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
> > index ef3b116492df08..47bcc6248a1338 100644
> > --- a/Documentation/process/2.Process.rst
> > +++ b/Documentation/process/2.Process.rst
> > @@ -13,24 +13,12 @@ how the process works is required in order to be an effective part of it.
> >   The big picture
> >   ---------------
> > -The kernel developers use a loosely time-based release process, with a new
> > -major kernel release happening every two or three months.  The recent
> > -release history looks like this:
> > -
> > -	======  =================
> > -	5.0	March 3, 2019
> > -	5.1	May 5, 2019
> > -	5.2	July 7, 2019
> > -	5.3	September 15, 2019
> > -	5.4	November 24, 2019
> > -	5.5	January 6, 2020
> > -	======  =================
> > -
> > -Every 5.x release is a major kernel release with new features, internal
> > -API changes, and more.  A typical release can contain about 13,000
> > -changesets with changes to several hundred thousand lines of code.  5.x is
> > -the leading edge of Linux kernel development; the kernel uses a
> > -rolling development model which is continually integrating major changes.
> > +The kernel developers use a loosely time-based, rolling release development
> > +process. A new major kernel release (a.x) happens every two or three months,
> > +which comes with new features, internal API changes, and more. A typical
> > +release can contain about 13,000 changesets with changes to several hundred
> > +thousand lines of code. Recent releases, along with their dates, can be found
> > +at `Linux Kernel Newbies site <https://kernelnewbies.org/LinuxVersions>`_.
> >   A relatively straightforward discipline is followed with regard to the
> >   merging of patches for each release.  At the beginning of each development
> > @@ -46,13 +34,12 @@ merge window do not come out of thin air; they have been collected, tested,
> >   and staged ahead of time.  How that process works will be described in
> >   detail later on).
> > -The merge window lasts for approximately two weeks.  At the end of this
> > -time, Linus Torvalds will declare that the window is closed and release the
> > -first of the "rc" kernels.  For the kernel which is destined to be 5.6,
> > -for example, the release which happens at the end of the merge window will
> > -be called 5.6-rc1.  The -rc1 release is the signal that the time to
> > -merge new features has passed, and that the time to stabilize the next
> > -kernel has begun.
> > +The merge window lasts for approximately two weeks. At the end of this time,
> > +Linus Torvalds will declare that the window is closed and release the first of
> > +the "rc" kernels.  For the kernel which is destined to be a.x, the release
> > +which happens at the end of the merge window will be called a.x-rc1. That
> > +release is the signal that the time to merge new features has passed, and that
> > +the time to stabilize the next kernel has begun.
> >   Over the next six to ten weeks, only patches which fix problems should be
> >   submitted to the mainline.  On occasion a more significant change will be
> > @@ -99,13 +86,13 @@ release is made.  In the real world, this kind of perfection is hard to
> >   achieve; there are just too many variables in a project of this size.
> >   There comes a point where delaying the final release just makes the problem
> >   worse; the pile of changes waiting for the next merge window will grow
> > -larger, creating even more regressions the next time around.  So most 5.x
> > +larger, creating even more regressions the next time around.  So most
> >   kernels go out with a handful of known regressions though, hopefully, none
> >   of them are serious.
> >   Once a stable release is made, its ongoing maintenance is passed off to the
> >   "stable team," currently Greg Kroah-Hartman. The stable team will release
> > -occasional updates to the stable release using the 5.x.y numbering scheme.
> > +occasional updates to the stable release using the a.x.y numbering scheme.
> >   To be considered for an update release, a patch must (1) fix a significant
> >   bug, and (2) already be merged into the mainline for the next development
> >   kernel. Kernels will typically receive stable updates for a little more
> > 
> > Thanks.
> > 
> I actually think this works better instead of removing the version numbers
> entirely or updating release numbers every year. Might be worth it to look
> for other pages in the documentation that have hard-coded version numbers
> and changing them also so that the version numbers don't need to be updated
> with every release.

OK, thanks!

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]