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@xxxxxxxxxxx> 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:
signature.asc
Description: PGP signature
