From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13878 invoked by alias); 4 Aug 2004 17:05:40 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 13870 invoked from network); 4 Aug 2004 17:05:39 -0000 Received: from unknown (HELO mail.amplepower.com) (216.39.162.139) by sourceware.org with SMTP; 4 Aug 2004 17:05:39 -0000 Received: from [192.168.8.30] (helo=knuth.amplepower.com ident=roth) by mail.amplepower.com with esmtp (Exim 3.36 #1 (Debian)) id 1BsPCr-0000mf-00; Wed, 04 Aug 2004 10:05:37 -0700 Date: Wed, 04 Aug 2004 17:05:00 -0000 From: "Theodore A. Roth" X-X-Sender: roth@knuth.amplepower.com To: Andrew Cagney cc: gdb@sources.redhat.com Subject: Re: dot five-o series versions - GDB 6.2.50 In-Reply-To: <41110F1A.3080706@gnu.org> Message-ID: References: <41110F1A.3080706@gnu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-08/txt/msg00035.txt.bz2 On Wed, 4 Aug 2004, Andrew Cagney wrote: > Hello, > > Ref: http://www.iro.umontreal.ca/translation/HTML/maintainers.html > > The translators are looking for a versioning schema that makes it easy > to undersand how two versions relate to each other. Unfortunatly, GDB's > current versioning doesn't do this. Without knowing the policy, it's > hard to know whats going on with: > > 2004-09-03 > 6.2_2004-09_03 > > consequently, I'd like to propose that things be changed to the following: > > M.N.5x: > Indicate the mainline. It's half way between releases -> .50. > Ex 6.2.50, 6.2.50_2004-09-03 > > M.N.9x: > Indicate pre release versions drawn from the branch. > > M.N / M.N.O: > The release. > > This leads to the sequence: > > 6.2.50_2004-09-03 > 6.2.50_2004-09-04 > ... > -----------> > 6.2.90_2004-10-05 6.3.50_2004-10-05 > 6.2.91 6.3.50_2004-10-06 > ... ... > 6.2.91_2004-10-10 6.3.50_2004-10-10 > ... ... > 6.3 6.3.50_2004-10-11 > ... ... > 6.3_2004-10-12 6.3.50_2004-10-12 > ... ... > 6.3.1 6.3.50_2004-10-13 > ... ... > ... > ... > ----------> > 6.2.90_2004-10-05 6.3.50_2004-10-05 > 6.2.91 6.3.50_2004-10-06 > ... ... > 6.2.91_2004-10-10 6.3.50_2004-10-10 > ... ... > 6.3 6.3.50_2004-10-11 > ... ... > 6.3_2004-10-12 6.3.50_2004-10-12 > ... ... > 6.3.1 6.3.50_2004-10-13 > ... ... > ... > ... > > comment! For the projects that I maintain, I found that versioning releases with M.N.P and then tacking on the date for anything from cvs works great and there is no ambiguity with where a version is coming from. Also if the version is purely numeric, it makes life a little easier for package maintainers since there is always a linear progression into the future. For example, 6.3.0 6.3.0.20041012 6.3.1 6.3.50.20041012 6.3.90.20041012 Of course, once 6.4 is branched (i.e. 6.3.90.xxxx is started), then mainline would need to go to 6.4.50.xxxx. Anyways, having something other than just the date for the verion of mainline would be nice. --- Ted Roth PGP Key ID: 0x18F846E9 Jabber ID: troth@jabber.org