From rock-devel-bounces@rocklinux.org Fri Jan 28 23:14:03 2005 Received: from phoenix.clifford.at (localhost.localnet [127.0.0.1]) by phoenix.clifford.at (8.12.10/8.12.10) with ESMTP id j0SME12c016310; Fri, 28 Jan 2005 23:14:01 +0100 Received: from sheephost1.obster.org (postfix@sheephost1.obster.org [213.202.217.18]) by phoenix.clifford.at (8.12.10/8.12.10) with ESMTP id j0SMDx2b016305 for ; Fri, 28 Jan 2005 23:13:59 +0100 Received: from localhost (localhost [127.0.0.1]) by sheephost1.obster.org (Postfix) with ESMTP id 4FE302FCBE for ; Fri, 28 Jan 2005 23:13:16 +0100 (CET) Received: from sheephost1.obster.org ([127.0.0.1]) by localhost (sheephost1.obster.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30014-06-2 for ; Fri, 28 Jan 2005 23:13:13 +0100 (CET) Received: from [192.168.0.3] (unknown [82.139.198.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sheephost1.obster.org (Postfix) with ESMTP id 576462FCB8 for ; Fri, 28 Jan 2005 23:13:13 +0100 (CET) Message-ID: <41FAB921.2000502@obster.org> Date: Fri, 28 Jan 2005 23:13:53 +0100 From: Michael Obster User-Agent: Mozilla Thunderbird 0.8 (X11/20041109) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ROCK Development Mailing List Subject: Re: [rock-devel] patchlevel References: <20050128204537.GG5686@waterworld.anvame.net> In-Reply-To: <20050128204537.GG5686@waterworld.anvame.net> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at obster.org X-BeenThere: rock-devel@rocklinux.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ROCK Development Mailing List List-Id: ROCK Development Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rock-devel-bounces@rocklinux.org Errors-To: rock-devel-bounces@rocklinux.org Hi, Andreas V. Meier wrote: > another thing I would like to clarify is the use of the patchlevel or > also called extra version field. > IMHO it should be increasend in every case where the resulting package > changes, be it an added patch, an added option or something like that. > > Updates to the package should always reset the patchlevel to 0. > let me make an example to get it clear. 1. cups on version 1.1.23 (initial patchlevel 1) 2. i change s.th. ==> patchlevel increase (to 2) 3. i change s.th. ==> patchlevel increase (to 3) 4. update to version 1.1.24 ==> patchlevel reset (to 1) ... Blindcoders summary says: -------------snip------------------ - - when / how to update $extraver for package modifications It has been defined that the extraversion starts with 1 and will be counted up automatically if anything but the major version or cache files in the package changes. This will be done independent in trunk and in branches. If the major version changes the extraversion will be reset to 1. Indirect updates (like packages linking libraries statically) the update must be done manually. --------------snap------------------ Cheers, Michael Obster -- mailto: michael@obster.org https://www.obster.org _______________________________________________ rock-devel mailing list rock-devel@rocklinux.org https://www.rocklinux.net/mailman/listinfo/rock-devel