From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B92FEC433DB for ; Thu, 4 Feb 2021 20:28:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6EF2064DAF for ; Thu, 4 Feb 2021 20:28:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240125AbhBDU2Y (ORCPT ); Thu, 4 Feb 2021 15:28:24 -0500 Received: from manchmal.in-ulm.de ([217.10.9.201]:59194 "EHLO manchmal.in-ulm.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240103AbhBDU2N (ORCPT ); Thu, 4 Feb 2021 15:28:13 -0500 X-Greylist: delayed 475 seconds by postgrey-1.27 at vger.kernel.org; Thu, 04 Feb 2021 15:28:11 EST Date: Thu, 4 Feb 2021 21:19:33 +0100 From: Christoph Biedl To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: Kernel version numbers after 4.9.255 and 4.4.255 Message-ID: <1612468714@msgid.manchmal.in-ulm.de> References: <7pR0YCctzN9phpuEChlL7_SS6auHOM80bZBcGBTZPuMkc6XjKw7HUXf9vZUPi-IaV2gTtsRVXgywQbja8xpzjGRDGWJsVYSGQN5sNuX1yaQ=@protonmail.com> <78ada91b-21ee-563f-9f75-3cbaeffafad4@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org 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