From: "Theodore A. Roth" <troth@openavr.org>
To: Andrew Cagney <cagney@gnu.org>
Cc: gdb@sources.redhat.com
Subject: Re: dot five-o series versions - GDB 6.2.50
Date: Wed, 04 Aug 2004 17:05:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.53.0408040945140.25078@knuth.amplepower.com> (raw)
In-Reply-To: <41110F1A.3080706@gnu.org>
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
> ...
> <branch> -----------> <mainline>
> 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 <release> 6.3.50_2004-10-11
> ... ...
> 6.3_2004-10-12 6.3.50_2004-10-12
> ... ...
> 6.3.1 <release> 6.3.50_2004-10-13
> ... ...
> <close> ...
> ...
> <branch> ----------> <mainline>
> 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 <release> 6.3.50_2004-10-11
> ... ...
> 6.3_2004-10-12 6.3.50_2004-10-12
> ... ...
> 6.3.1 <release> 6.3.50_2004-10-13
> ... ...
> <close> ...
> ...
>
> 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 <release>
6.3.0.20041012 <cvs-6.3-branch>
6.3.1 <release>
6.3.50.20041012 <cvs-mainline>
6.3.90.20041012 <cvs-6.4-branch pre-release>
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
next prev parent reply other threads:[~2004-08-04 17:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-04 16:30 Andrew Cagney
2004-08-04 16:36 ` Dave Korn
2004-08-04 16:54 ` Andrew Cagney
2004-08-04 16:56 ` Daniel Jacobowitz
2004-08-11 17:38 ` Andrew Cagney
2004-08-04 17:05 ` Theodore A. Roth [this message]
2004-08-04 21:11 ` Steven Johnson
2004-08-04 21:27 ` Andrew Cagney
2004-08-04 23:16 jyates
2004-08-05 10:08 ` Andreas Schwab
2004-08-05 13:49 jyates
2004-08-05 15:41 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.53.0408040945140.25078@knuth.amplepower.com \
--to=troth@openavr.org \
--cc=cagney@gnu.org \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox