From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757502AbcAaPG7 (ORCPT ); Sun, 31 Jan 2016 10:06:59 -0500 Received: from mailapp01.imgtec.com ([195.59.15.196]:28943 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757218AbcAaPG5 (ORCPT ); Sun, 31 Jan 2016 10:06:57 -0500 Date: Sun, 31 Jan 2016 15:05:49 +0000 From: "Maciej W. Rozycki" To: Alexander Kapshuk CC: Daniel Sanders , James Hogan , "Michael S. Tsirkin" , LKML , Michal Marek , "linux-kbuild@vger.kernel.org" , Linux MIPS Mailing List , Ralf Baechle Subject: Re: [PATCH] ld-version: fix it on Fedora In-Reply-To: Message-ID: References: <1452189189-31188-1-git-send-email-mst@redhat.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [10.100.200.149] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 30 Jan 2016, Maciej W. Rozycki wrote: > > % echo 2.24.51.20140217 | ld-version.sh > > 22451000 > > So the above version is a non-release snapshot from the development tree > as the repository trunk is switched to x.y+1.51 once a release branch for > x.y has been made. Then the release branch is switched to x.y-1.90 for > prereleases, before settling on x.y or x.y.0 (this hasn't been consistent) > for the actual base release. Any subsequent maintenance releases will > then have their version set to x.y.1, x.y.2, and so on. We shouldn't ever > rely on versions that are not proper releases. I need to correct myself here for unclear notation or off-by-one errors, the flow is of course as follows: trunk x.y-1.51 | | | release branchpoint | \ x.y.51 x.y-1.90 | prerelease | | | | v x.y-1.91 . prerelease . | . | | x.y-1.92 prerelease . . . x.y.0 base release | | | x.y.1 maintenance release | | | x.y.2 maintenance release | v . . . The revision number is sometimes bumped up on trunk as well, to 52, 53, etc., though the criteria are not completely clear to me; perhaps to make a trunk snapshot "release". And last but not least for non-release builds the snapshot date is automatically appended to the version number reported, as seen above. Maciej