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

[Bagas Sanjaya <bagasdotme@gmail.com>]

[-- 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 --]