linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: Kernel version numbers after 4.9.255 and 4.4.255
Date: Thu, 4 Feb 2021 21:19:33 +0100	[thread overview]
Message-ID: <1612468714@msgid.manchmal.in-ulm.de> (raw)
In-Reply-To: <b17b4c3b2e4b45f9b10206b276b7d831@AcuMS.aculab.com>

David Laight wrote...

> A full wrap might catch checks for less than (say) 4.4.2 which
> might be present to avoid very early versions.
> So sticking at 255 or wrapping onto (say) 128 to 255 might be better.

Hitting such version checks still might happen, though.

Also, any wrapping introduces a real risk package managers will see
version numbers running backwards and therefore will refrain from
installing an actually newer version.

For scripts/package/builddeb (I don't use that, though), you could work
around by setting an epoch, i.e. (untested)

-$sourcename ($packageversion) $distribution; urgency=low
+$sourcename (1:$packageversion) $distribution; urgency=low

but every packaging mechanism in-tree and outside should adopt such a
change, if even possible. Which is why this feels bad.

Possibly I am missing something: What's the reason to not use
EXTRAVERSION as back in the old 2.6.x.y days, so change to 4.4.255.1 and
so on? Well, unless there are still installations who treat 4.4.255 as
2.6.64.255.

    Christoph

  parent reply	other threads:[~2021-02-04 20:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-04  5:59 Jari Ruusu
2021-02-04  6:20 ` Greg Kroah-Hartman
2021-02-04  7:26   ` Jiri Slaby
2021-02-04  8:51     ` Greg Kroah-Hartman
2021-02-04 11:00       ` Jiri Slaby
2021-02-04 16:28         ` David Laight
2021-02-04 16:48           ` Greg Kroah-Hartman
2021-02-04 20:19           ` Christoph Biedl [this message]
2021-02-05  6:52             ` Greg KH
2021-02-05 17:31         ` Tony Battersby
2021-02-05 18:11           ` Mauro Carvalho Chehab
2021-02-06  7:20             ` Greg Kroah-Hartman
2021-02-06  9:24               ` Mauro Carvalho Chehab
2021-02-06  9:29                 ` Greg Kroah-Hartman
2021-02-06  9:48                   ` Mauro Carvalho Chehab
2021-02-06 10:18                     ` Hans Verkuil
2021-02-06 11:18                       ` Mauro Carvalho Chehab
2021-02-06  7:22           ` Greg Kroah-Hartman
2021-02-05  9:06       ` Pavel Machek
2021-02-05  9:33         ` Greg Kroah-Hartman
2021-02-05 18:44           ` Pavel Machek
2021-02-06  7:23             ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1612468714@msgid.manchmal.in-ulm.de \
    --to=linux-kernel.bfrz@manchmal.in-ulm.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --subject='Re: Kernel version numbers after 4.9.255 and 4.4.255' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).