Re: [PATCH] Documentation: process: Do not hardcode kernel major version number

[Jonathan Corbet <corbet@lwn.net>]

Bagas Sanjaya <bagasdotme@gmail.com> writes:

> The big picture section of 2.Process.rst currently hardcodes major
> version number to 5 since fb0e0ffe7fc8e0 ("Documentation: bring process
> docs up to date"). As it can get outdated when it is actually
> incremented (the recent is 6 and will be 7 in the near future), replace
> it with the placeholder.
>
> Note that the version number examples are kept to illustrate the
> numbering scheme.
>
> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
> ---
>  Documentation/process/2.Process.rst | 40 ++++++++++++-----------------
>  1 file changed, 17 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
> index ef3b116492df08..668d5559ded039 100644
> --- a/Documentation/process/2.Process.rst
> +++ b/Documentation/process/2.Process.rst
> @@ -13,24 +13,18 @@ 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:
> +Linux kernel uses a loosely time-based, rolling release development model.
> +A new major kernel release (a.x) [1]_ happens every two or three monts, 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
> +`Wikipedia <https://en.wikipedia.org/wiki/Linux_kernel_version_history>`_.

I have to admit that I'm not at all convinced that this change brings
clarity to the document; using real numbers grounds the text in a way
that "a.x" does not.

If we really think it's embarrassing to still say "5.whatever" here,
perhaps we should just change it to "9.whatever" and be good for a long
time?

Thanks,

jon