RE: dot five-o series versions - GDB 6.2.50

RE: dot five-o series versions - GDB 6.2.50

[jyates]

Wow!  Learn something new everyday!

Neither ls --help nor man ls provide a much of a clue
as to what a version sort is.  Listed among items with
more obvious sorting semantics I simply ignored -v.
info ls provided the full story.  ls -v definitely
addresses my objection.

/john


-----Original Message-----
From: Andreas Schwab [mailto:schwab@suse.de]
Sent: Thursday, August 05, 2004 6:09 AM
To: John Yates
Cc: gdb@sources.redhat.com
Subject: Re: dot five-o series versions - GDB 6.2.50


<jyates@netezza.com> writes:

> That would be fine if commonplace sorts obeyed that logic.
> The most common sort in my world is /bin/ls which fails to
> conform.

GNU ls: --sort=version (aka -v)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: dot five-o series versions - GDB 6.2.50

[Andrew Cagney]

> Wow!  Learn something new everyday!
> 
> Neither ls --help nor man ls provide a much of a clue
> as to what a version sort is.  Listed among items with
> more obvious sorting semantics I simply ignored -v.
> info ls provided the full story.  ls -v definitely
> addresses my objection.
> 
> /john

For what its worth, I think if we [gdb] find ourselves doing more than 
4 re-spins (a.k.a. point releases) from a branch, we've got far bigger 
problems :-)

Andrew

Re: dot five-o series versions - GDB 6.2.50

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 99 bytes --]

Re-post.  I think the concerns were resolved, I'll look to deploy this 
in a couple weeks.

Andrew

[-- Attachment #2: Attached Message --]
[-- Type: message/rfc822, Size: 4438 bytes --]

From: Andrew Cagney <cagney@gnu.org>
To: gdb@sources.redhat.com
Cc: Dave Korn <dk@artimi.com>
Subject: Re: dot five-o series versions - GDB 6.2.50
Date: Wed, 04 Aug 2004 12:54:44 -0400
Message-ID: <411114D4.1000108@gnu.org>

>   Cut'n'paste error, or have I not understood the convention you were using
> in that diagram?  Or both?
> 
Mutter something rude, attempt #2.  thanks :-)

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.3.90_2004-10-05     6.4.50_2004-10-05
                       6.3.91                6.4.50_2004-10-06
                       ...                   ...
                       6.3.91_2004-10-10     6.4.50_2004-10-10
                       ...                   ...
                       6.4 <release>         6.4.50_2004-10-11
                       ...                   ...
                       6.4_2004-10-12        6.4.50_2004-10-12
                       ...                   ...
                       6.4.1 <release>       6.4.50_2004-10-13
                       ...                   ...
                       <close>               ...
                                             ...

comment!

Andrew

Re: dot five-o series versions - GDB 6.2.50

[Andreas Schwab]

<jyates@netezza.com> writes:

> That would be fine if commonplace sorts obeyed that logic.
> The most common sort in my world is /bin/ls which fails to
> conform.

GNU ls: --sort=version (aka -v)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: dot five-o series versions - GDB 6.2.50

[jyates]

Andrew Cagney wrote:

...

> cagney@nettle$ sort -t. -k1,1n -k2,2n -k3,3n x

...

> I'm not sure I understand the problem, dot is a field separator rather 
> than decimal place.

That would be fine if commonplace sorts obeyed that logic.
The most common sort in my world is /bin/ls which fails to
conform.  Any scheme is which lexical sorting produced a
correct result would be preferable.

/john

Re: dot five-o series versions - GDB 6.2.50

[Andrew Cagney]

> The only comment I habe is you wouldnt want any more than 4 point releases, before it got confusing.
> 
> Because as a number .5 = .50, and .6 is greater than .50
> 
> So either the rule should be no more than 4 M.N.* Releases. or when you get to .4, you start going to .41, .42, .43 etc
> or just number from .01 ie 6.3.01  otherwise the sequence isnt numeric, its a list of numbers and wont sort properly (using standard ascii or numberic sorts).

cagney@nettle$ cat x
6.2
6.2.1
6.2.90
6.2.2
6.2.50
6.2.3
6.2.51
6.2.4
6.2.52
6.2.5
6.2.91
6.2.6
6.2.54
6.2.7
6.2.93
6.2.8
6.2.53
6.2.9
6.2.92
6.2.10
cagney@nettle$ sort -t. -k1,1n -k2,2n -k3,3n x
6.2
6.2.1
6.2.2
6.2.3
6.2.4
6.2.5
6.2.6
6.2.7
6.2.8
6.2.9
6.2.10
6.2.50
6.2.51
6.2.52
6.2.53
6.2.54
6.2.90
6.2.91
6.2.92
6.2.93

("n" likes to consume "." which breaks the simpler -k1,3n)

 > So basically does .1 mean .01 and if so why not call it .01?

I'm not sure I understand the problem, dot is a field separator rather 
than decimal place.

Andrew

Re: dot five-o series versions - GDB 6.2.50

[Steven Johnson]

The only comment I habe is you wouldnt want any more than 4 point 
releases, before it got confusing.

Because as a number .5 = .50, and .6 is greater than .50

So either the rule should be no more than 4 M.N.* Releases. or when you 
get to .4, you start going to .41, .42, .43 etc
or just number from .01 ie 6.3.01  otherwise the sequence isnt numeric, 
its a list of numbers and wont sort properly (using standard ascii or 
numberic sorts).

So basically does .1 mean .01 and if so why not call it .01?

Steven

ie,

6.3_2004-10-12        6.3.50_2004-10-12
...                   ...
6.3.1 <release>       6.3.50_2004-10-13

6.3_2004-10-14        6.3.50_2004-10-14
...                   ...
6.3.2 <release>       6.3.50_2004-10-15

6.3_2004-10-16        6.3.50_2004-10-16
...                   ...
6.3.3 <release>       6.3.50_2004-10-17

6.3_2004-10-18        6.3.50_2004-10-18
...                   ...
6.3.4 <release>       6.3.50_2004-10-19

6.3_2004-10-21        6.3.50_2004-10-21
...                   ..
6.3.5 <release>       6.3.50_2004-10-22

6.3_2004-10-23        6.3.50_2004-10-23
...                   ...
6.3.6 <release>       6.3.50_2004-10-24


[BIG SNIP]

Re: dot five-o series versions - GDB 6.2.50

[Theodore A. Roth]

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

Re: dot five-o series versions - GDB 6.2.50

[Daniel Jacobowitz]

On Wed, Aug 04, 2004 at 12:54:44PM -0400, Andrew Cagney wrote:
> >  Cut'n'paste error, or have I not understood the convention you were using
> >in that diagram?  Or both?
> >
> Mutter something rude, attempt #2.  thanks :-)
> 
> 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 looks like a great idea to me.

-- 
Daniel Jacobowitz

Re: dot five-o series versions - GDB 6.2.50

[Andrew Cagney]

>   Cut'n'paste error, or have I not understood the convention you were using
> in that diagram?  Or both?
> 
Mutter something rude, attempt #2.  thanks :-)

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.3.90_2004-10-05     6.4.50_2004-10-05
                       6.3.91                6.4.50_2004-10-06
                       ...                   ...
                       6.3.91_2004-10-10     6.4.50_2004-10-10
                       ...                   ...
                       6.4 <release>         6.4.50_2004-10-11
                       ...                   ...
                       6.4_2004-10-12        6.4.50_2004-10-12
                       ...                   ...
                       6.4.1 <release>       6.4.50_2004-10-13
                       ...                   ...
                       <close>               ...
                                             ...

comment!

Andrew

RE: dot five-o series versions - GDB 6.2.50

[Dave Korn]

> -----Original Message-----
> From: gdb-owner On Behalf Of Andrew Cagney
> Sent: 04 August 2004 17:30

> This leads to the sequence:
> 
> 6.2.50_2004-09-03
> 6.2.50_2004-09-04
> ...
>      <branch> -----------> <mainline>

  Mainline comes off a branch?

> 6.3 <release>         6.3.50_2004-10-11
> 6.3.1 <release>       6.3.50_2004-10-13

>                        6.3 <release>         6.3.50_2004-10-11
>                        6.3.1 <release>       6.3.50_2004-10-13

  How many releases of each version?

> comment!

  Cut'n'paste error, or have I not understood the convention you were using
in that diagram?  Or both?

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....
 

dot five-o series versions - GDB 6.2.50

[Andrew Cagney]

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!

Andrew