Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757002AbZJFQla (ORCPT ); Tue, 6 Oct 2009 12:41:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756799AbZJFQl3 (ORCPT ); Tue, 6 Oct 2009 12:41:29 -0400 Received: from mx3.mail.elte.hu ([157.181.1.138]:46094 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756651AbZJFQl2 (ORCPT ); Tue, 6 Oct 2009 12:41:28 -0400 Date: Tue, 6 Oct 2009 18:40:28 +0200 From: Ingo Molnar To: Linus Torvalds Cc: Dirk Hohndel , Len Brown , Linux Kernel Mailing List Subject: Re: Linux 2.6.32-rc3 Message-ID: <20091006164028.GA23305@elte.hu> References: <1254797502.14122.146.camel@dhohndel-mobl.amr.corp.intel.com> <20091006144449.GA23078@elte.hu> <20091006153632.GA29795@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.5 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2160 Lines: 66 * Linus Torvalds wrote: > On Tue, 6 Oct 2009, Linus Torvalds wrote: > > > > Unless: > > > > > _That_ i think is a lot harder to confuse with the real .31 than a > > > v2.6.31-1234-g16123c4 version string. > > > > .. are you saying that it would be just some automatically generated > > thing, just a crippled form of CONFIG_LOCALVERSION_AUTO? Kind of a > > CONFIG_LOCALVERSION_AUTO_SHORTFORM? > > So how about this? > > It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial > way: > > - if it is set, things work the way they always have, and you get a > extended kernel release like > > 2.6.32-rc3-00052-g0eca52a-dirty > > - but if it is _not_ set, we'll still try to get a version from the > underlying SCM (we actually support git, hg and SVN right now, even if > some comments may say "git only"), and if the underlying SCM says it > has a local version, we append just "+", so you get a version number > like > > 2.6.32-rc3+ > > IOW, you'd never get 2.6.32-rc0, but you'd get either the complex git > version number (or SVN/hg/whatever), or at least "2.6.31+" with the "+" > showing that it is more than plain 2.6.31. > > The "+" could be anything else, of course. The diff is pretty obvious, > you can argue about exactly _what_ you'd like to see as a suffix for > "and then some". Could we, for consistency's sake, make it: 2.6.32-rc3+00052-g0eca52a-dirty 2.6.32-rc3+ ? Or do we want to keep the old version string alone for some reason? The reason is that i have been confused in the past by having seen something like: 2.6.29-00052-g0eca52a-dirty and parsing out (in an admittedly weak moment) the gibberish after the first dash. Had it said: 2.6.29+00052-g0eca52a-dirty i'm sure i'd have noticed that it's not vanilla v2.6.29 - that plus sign stands out like a lightning rod. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/