Message-ID: <aEeqcX78zipEGJkl@archie.me>
Date: Tue, 10 Jun 2025 10:45:53 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: Jonathan Corbet <corbet@....net>,
	Dante Strock <dantestrock@...mail.com>
Cc: Linux Documentation <linux-doc@...r.kernel.org>,
	Linux Kernel Workflows <workflows@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Documentation/process/: Change 5.x to 6.x; clarify
 terms; added note.

On Mon, Jun 09, 2025 at 08:37:05AM -0600, Jonathan Corbet wrote:
> Dante Strock <dantestrock@...mail.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

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists