CVS versions of gdb have same number as stable version.

CVS versions of gdb have same number as stable version.

[Michael Elizabeth Chastain]

Okay, I'm looking at a PR (gdb/7), and the user has pasted in their
gdb startup message:

  GNU gdb 5.0
  Copyright 2000 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you are
  welcome to change it and/or distribute copies of it under certain conditions.
  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB. Type "show warranty" for details.
  This GDB was configured as "i686-pc-linux-gnu"...

Quick, which version of gdb is this?

It might be gdb 5.0.  Or it might be any CVS version of gdb made between
the release of gdb 5.0 and 2001-01-24 (when the copyright date changed
to 2001).

This bothers me.  I've filed a PR about it.

Can we please use something other than "5.0" for CVS gdb, such as
"5.1-experimental-$(DATE)", or even just "5.1-experimental"?

Michael

Re: CVS versions of gdb have same number as stable version.

[Andrew Cagney]

Michael Elizabeth Chastain wrote:

> This bothers me.  I've filed a PR about it.

Why not fix it?  I'm sure you're sufficiently expert in CVS to figure
out the magic we need to add to change that line.

As for snapshots, they already get a time stamp.

	Andrew

Re: CVS versions of gdb have same number as stable version.

[Andrew Cagney]

Hmm, this turned out to be a hot topic, sorry ... :-)

--

First the easy bit:

Given that there doesn't appear to be any way of wacking
Makefile.in:VERSION during a CVS ci/co, I'd like to adapt CGF's
suggestion into the following:

	o	shove VERSION into a
		separate file.

		Please don't ask which
		file, I neither know nor
		care :-)

	o	add cronjobs to wack
		that file daily.

		The wack would occure
		at about 00:00GMT.

		An alternative might be
		00:00 FJT but I suspect
		GMT/UCT is best.

		Who ever sets this up had
		better remember daylight
		savings :-)

		What the wack does is
		discused below.

Pratmatics:

By putting version into its own little (very booring) file all the dummy
CVS commits are isolated.

The current snapshots are created at about 02:00GMT using 00:00 GMT as
the -D parameter.  In theory, the hack that wacks the snapshot's VERSION
becomes redundant.  In reality, I bet there is a race condition so that
hack should continue :-)

--

Now the more interesting bit:

Back in the good old days of ``open development'', everything was made
available using snapshots (GDB, BINUTILS, GCC all did this).  During the
release cycle, the snaps would follow the branch and not the trunk vis

   trunk -> trunk               .-> warp-to-trunk
	      `-> branch -> release

Since the general public only saw the above flow, problems like
differentiating between trunks and branches didn't occure.  A convention
like 4.18 -> 4.18.0.90 -> 4.18.90(branch) -> 4.18.91 -> 5.0 -> 5.0.0.90
made pretty good sense.

With CVS however, things are very different.  I don't think that the
above model still applies.  The flow is now:

                    .-> branch -> release (YYYYMMDD-bigted-1.2.3)
trunk -> trunk -> trunk -> trunk -> trunk -> trunk
   `-> branch -> release 5.1
          `-> branch -> release 5.1.1
                            `-> release 5.1.1-littleted-123

(and you thought life was easy :-)  The trunk and the branchs are all
active at the same time. Patches are constantly, and randomly, been
applied.

With that in mind my first thought was:

  trunk: gdb-YYYYMMDD (gdb-20010229)
  branch: gdb-B.B.B-YYYY-MM-DD (gdb-5.0.90-20010229)

However, I've been ``educated'' by marketing :-)  People like to know
the last release that a snapshot is based on.  With that in mind could I
suggest:

  trunk: gdb-R.R.R-YYYYMMDD (gdb-5.0-20010229)
  branch: gdb-R.R.R.BB (gdb-5.0.90, ....)

Where ``R.R.R'' is the last official release.  When ever a release is
made, the trunk is updated to reflect this.

The trunk would be date stamped daily.

A branch could also get a daily date stamp but, well, I suspect that is
over kill.

Looking at the likely 5.1 senario:

  trunk: gdb-5.0-20030229
  5.1 branch: gdb-5.0.90, gdb-5.0.91, ...

(Strictly speaking) when 5.1 was released things would follow:

  trunk: gdb-5.1-20042301
  5.1 branch: ...gdb-5.0.99, gdb-5.1 frozen
  5.1.1 branch: gdb-5.1.0.90 ....

However, being essentially lazy, I'd actually do:

  trunk: gdb-5.1-20054705
  5.1 branch: gdb-5.0.99, gdb-5.1 (tag), gdb-5.1.0.90, ...

Oh, if you work this through, there is a small window during which both
the trunk and the branch could produce the version number
gdb-5.1-YYYYMMDD.  I'll try to remember to not make the release during
00:00 GMT :-)

So again, to restart this discussion .... :-)  Comments?

	Andrew

Re: CVS versions of gdb have same number as stable version.

[Fernando Nasser]

Andrew,

IMO the trunk should print something print R+1 (with something like
alpha, experimental, ot the like) to avoid confusion with the release. 
This makes clear to people that they have something that have things
added,/removed/modified for more reasons than just bug fixes.

It is conceptually more appropriate as well, as the trunk sources are
what will become the next release.

Just my 2cents.

Fernando



Andrew Cagney wrote:
> 
>   trunk: gdb-R.R.R-YYYYMMDD (gdb-5.0-20010229)
>   branch: gdb-R.R.R.BB (gdb-5.0.90, ....)
> 

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: CVS versions of gdb have same number as stable version.

[Kevin Buettner]

On Mar 3,  2:45pm, Andrew Cagney wrote:

> With that in mind my first thought was:
> 
>   trunk: gdb-YYYYMMDD (gdb-20010229)
>   branch: gdb-B.B.B-YYYY-MM-DD (gdb-5.0.90-20010229)

Of the various schemes that you proposed, I like this one the best.
(I don't like the release number showing up in the trunk versions.)

Kevin

Re: CVS versions of gdb have same number as stable version.

[Fernando Nasser]

Kevin Buettner wrote:
> 
> On Mar 3,  2:45pm, Andrew Cagney wrote:
> 
> > With that in mind my first thought was:
> >
> >   trunk: gdb-YYYYMMDD (gdb-20010229)
> >   branch: gdb-B.B.B-YYYY-MM-DD (gdb-5.0.90-20010229)
> 
> Of the various schemes that you proposed, I like this one the best.
> (I don't like the release number showing up in the trunk versions.)
> 

Yes, that one addresses my concerns as well.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: CVS versions of gdb have same number as stable version.

[Andrew Cagney]

>   trunk: gdb-YYYYMMDD (gdb-20010229)
>   branch: gdb-B.B.B-YYYYMMDD (gdb-5.0.90-20010229)

It appears that the consensus is with this one. Any further comment?

MichaelC expressed concern over being able to differentiate between a
CVS gdb-20010229 and a snapshot gdb-20010229.  Yes, they can differ
significantly.

That would mean that something like:

	$ gdb
	GNU gdb 4.17

will become

	$ gdb
	GNU gdb 20010229 (cvs)
and	GNU gdb 5.0.90-20010229 (snap)

or	GNU gdb 20010229-cvs
and	GNU gdb 5.0.90-20010229

assuming no further comment, I'm going to toss a coin and then choose
the second one :-)

	Andrew

Re: CVS versions of gdb have same number as stable version.

[Andrew Cagney]

I _think_ this problem is now fixed.

	Andrew

> Okay, I'm looking at a PR (gdb/7), and the user has pasted in their
> gdb startup message:
> 
>   GNU gdb 5.0
>   Copyright 2000 Free Software Foundation, Inc.
>   GDB is free software, covered by the GNU General Public License, and you are
>   welcome to change it and/or distribute copies of it under certain conditions.
>   Type "show copying" to see the conditions.
>   There is absolutely no warranty for GDB. Type "show warranty" for details.
>   This GDB was configured as "i686-pc-linux-gnu"...
> 
> Quick, which version of gdb is this?
> 
> It might be gdb 5.0.  Or it might be any CVS version of gdb made between
> the release of gdb 5.0 and 2001-01-24 (when the copyright date changed
> to 2001).
> 
> This bothers me.  I've filed a PR about it.
> 
> Can we please use something other than "5.0" for CVS gdb, such as
> "5.1-experimental-$(DATE)", or even just "5.1-experimental"?
> 
> Michael
> 
> 

Re: CVS versions of gdb have same number as stable version.

[Michael Elizabeth Chastain]

Hi Andrew,

I was sorta checking that no one would object to "5.1-experimental"
when I do submit it.

I'll just get out of my mailer and into my editor, then.  :)

Michael

Re: CVS versions of gdb have same number as stable version.

[Kevin Buettner]

On Feb 16,  8:46am, Michael Elizabeth Chastain wrote:

> I was sorta checking that no one would object to "5.1-experimental"
> when I do submit it.

I won't object, and I am in strong agreement that the version numbers
ought to be different between the release version and our development
versions.

However, I also think it'd be useful if the version strings between
different development versions are also different.  The easiest way
that I know to do this is to somehow incorporate a date string into
the version string.  Ideally, this date string should reflect the time
of the checkout (or update) and not of the build.

The best mechanism for doing this may take a while to figure out, so
it'd be best if you'd submit a simple patch for "5.1-experimental"
first.

Kevin

Re: CVS versions of gdb have same number as stable version.

[J.T. Conklin]

>>>>> "Michael" == Michael Elizabeth Chastain <chastain@cygnus.com> writes:
Michael> I was sorta checking that no one would object to
Michael> "5.1-experimental" when I do submit it.

The only issue I might have is that the "-experimental" tag tells you
it's not a real 5.1 release, it does not give you any clue from where
in the 5.1 development cycle the sources were cut.

Don't other GNU projects do things like 5.0.XX, where XX starts off at
a high number like 80 and is periodically incremented until the next
release?

Another alternative would be a date stamp, similar to GDB snapshots.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: CVS versions of gdb have same number as stable version.

[Eli Zaretskii]

> From: jtc@redback.com (J.T. Conklin)
> Date: 16 Feb 2001 11:02:25 -0800
> 
> Don't other GNU projects do things like 5.0.XX, where XX starts off at
> a high number like 80 and is periodically incremented until the next
> release?

They do, but during a pretest.  For development versions, we'd
probably need to begin with 5.0.1 and increment it ;-)

Re: CVS versions of gdb have same number as stable version.

[Michael Elizabeth Chastain]

Hi J. T.,

> Don't other GNU projects do things like 5.0.XX, where XX starts off at
> a high number like 80 and is periodically incremented until the next
> release?

I will change it to "5.0.90", or whatever, if a maintainer with the
authority to approve this patch specifies an exact string and states
that they will approve that string.

Then I'll check in such patch without another round of [RFA].

> Another alternative would be a date stamp, similar to GDB snapshots.

I think you mean "similar to gcc snapshots".  I'm not going to do that.
gcc has additional configury to do that, and I am not going to port that
configury and then qualify it on a bunch of platforms.

Instead I'm going to spend my time in gdb/7, analyzing why gdb core dumps
when I do "maint print symbols" in some gdb that calls itself 5.0 on the
user's system.  If I can get bleeding edge CVS gdb to quit calling itself
5.0, that makes my task easier.  (Not to mention I have a day job.)

If someone else wants to do "gdb ...-$(DATE)", great.  This patch won't
make their work any more difficult.

I hate this pattern:

  Would-be contributor notices a bug.
  Would-be contributor writes a patch.
  Maintainer says: "if you're going to fix the problem, how about doing
    lots more work while you are in there?"

My patch is on the table.

  -- approved?
  -- specific counter-proposal?
  -- rejected?

Michael

Re: CVS versions of gdb have same number as stable version.

[Andrew Cagney]

Michael Elizabeth Chastain wrote:

> > Another alternative would be a date stamp, similar to GDB snapshots.
> 
> I think you mean "similar to gcc snapshots".  I'm not going to do that.
> gcc has additional configury to do that, and I am not going to port that
> configury and then qualify it on a bunch of platforms.

J.T. ment GDB.

	Andrew

Re: CVS versions of gdb have same number as stable version.

[J.T. Conklin]

>>>>> "Michael" == Michael Elizabeth Chastain <chastain@cygnus.com> writes:
>> Don't other GNU projects do things like 5.0.XX, where XX starts off at
>> a high number like 80 and is periodically incremented until the next
>> release?

Michael> I will change it to "5.0.90", or whatever, if a maintainer with the
Michael> authority to approve this patch specifies an exact string and states
Michael> that they will approve that string.
Michael>
Michael> Then I'll check in such patch without another round of [RFA].

Sounds reasonable.  

>> Another alternative would be a date stamp, similar to GDB snapshots.

Michael> I think you mean "similar to gcc snapshots".  I'm not going
Michael> to do that.  gcc has additional configury to do that, and I
Michael> am not going to port that configury and then qualify it on a
Michael> bunch of platforms.

No, I meant gdb snapshots.  I don't know how GDB snapshots are made,
but my local GDB repository, which was last sync'd with the 20010108 
snapshot has VERSION=20010108 in gdb/Makefile.in.  

Michael> Instead I'm going to spend my time in gdb/7, analyzing why
Michael> gdb core dumps when I do "maint print symbols" in some gdb
Michael> that calls itself 5.0 on the user's system.  If I can get
Michael> bleeding edge CVS gdb to quit calling itself 5.0, that makes
Michael> my task easier.  (Not to mention I have a day job.)

This seems like a good use of your time.

Michael> I hate this pattern:
Michael>
Michael>   Would-be contributor notices a bug.
Michael>   Would-be contributor writes a patch.
Michael>   Maintainer says: "if you're going to fix the problem, how about 
Michael>                     doing lots more work while you are in there?"

Note that's not exactly what I said.  I think it is a good idea for a bit
of brainstorming to ensure that the problem is well understood, decisions 
are not clear cut, etc.  In the end, I think this results in a better out-
come.  Due to the distributed nature of GDB development, it increases 
latency, but that's a price that has to be paid.

As part of the debate, we determine whether a change is *the* solution
to the problem, or an incremental step towards the solution (and, in
rare cases, a step back that should be rejected).

But note, I think it is important that maintainers have the right to
reject a change and ask the submitter to do more work.  In the past,
we have accepted changes that clearly needed more work (e.g. TUI).
I'd like to avoid these types of mistakes in the future.

Michael> My patch is on the table.
Michael>   -- approved?
Michael>   -- specific counter-proposal?
Michael>   -- rejected?

None of the above?  

If I'm not misremembering the 5.0.XX convention (perhaps it's only
used for formal 5.1 test releases), I'd approve the change.  I
strongly prefer that form to "-experimental".  But I would prefer
input from others, cuz it seems somehow wrong to approve your own
proposal.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: CVS versions of gdb have same number as stable version.

[Kevin Buettner]

On Feb 16, 11:57am, J.T. Conklin wrote:

> If I'm not misremembering the 5.0.XX convention (perhaps it's only
> used for formal 5.1 test releases), I'd approve the change.  I
> strongly prefer that form to "-experimental".  But I would prefer
> input from others, cuz it seems somehow wrong to approve your own
> proposal.

I think that 5.0.XX makes sense for the branch that'll eventually be
created for the 5.1 release.  For the development sources, I think
that Michael C's suggestion of "5.1-experimental" (or whatever it was)
is preferable since it also clearly distinguishes between release
candidates and the ongoing development on the trunk.

Kevin

Re: CVS versions of gdb have same number as stable version.

[Elena Zannoni]

Kevin Buettner writes:
 > On Feb 16, 11:57am, J.T. Conklin wrote:
 > 
 > > If I'm not misremembering the 5.0.XX convention (perhaps it's only
 > > used for formal 5.1 test releases), I'd approve the change.  I
 > > strongly prefer that form to "-experimental".  But I would prefer
 > > input from others, cuz it seems somehow wrong to approve your own
 > > proposal.
 > 
 > I think that 5.0.XX makes sense for the branch that'll eventually be
 > created for the 5.1 release.  For the development sources, I think
 > that Michael C's suggestion of "5.1-experimental" (or whatever it was)
 > is preferable since it also clearly distinguishes between release
 > candidates and the ongoing development on the trunk.
 > 
 > Kevin
 > 

Let's look at the history:

1999-04-09  Jim Blandy  <jimb@zwingli.cygnus.com>

        * GDB 4.18 released.
        * Makefile.in (VERSION): Bump to 4.18.1.

Mon Mar  2 17:04:25 1998  Jason Molenda  (crash@bugshack.cygnus.com)

        * Makefile (VERSION): Bump to 4.17.1.

Mon Apr 22 20:17:01 1996  Fred Fish  <fnf@cygnus.com>

        * Makefile.in (VERSION): Bump version number to 4.16.1.
        * NEWS: Update for 4.16 release.

Wed Feb 28 15:50:12 1996  Fred Fish  <fnf@cygnus.com>

        * Makefile.in (VERSION): Bump version to 4.15.2 to establish
        baseline for gdb 4.16 rerelease testing.

Wed Oct 11 17:25:59 1995  Fred Fish  <fnf@rtl.cygnus.com>

        * Makefile.in (VERSION): Bump version to 4.15.1

Tue Oct 10 15:26:39 1995  Fred Fish  <fnf@cygnus.com>

        * Makefile.in (VERSION): Version 4.15 released.
        * README: Updated for version 4.15.
        * NEWS: Updated for 4.15 release.


Etc. Etc.


I am in favour of 5.0.1, which is consistent with what we did in the
past.

Elena

Re: CVS versions of gdb have same number as stable version.

[Kevin Buettner]

On Feb 16,  3:29pm, Elena Zannoni wrote:

> I am in favour of 5.0.1, which is consistent with what we did in the
> past.

Okay.  I believe that Eli mentioned this as well.

(I wonder if we could arrange for a script to bump the version number
on a weekly basis.)

Kevin

Re: CVS versions of gdb have same number as stable version.

[Andrew Cagney]

Elena Zannoni wrote:

> Etc. Etc.
> 
> I am in favour of 5.0.1, which is consistent with what we did in the
> past.

FYI,

With !*@($&)(!*@ C++ 3.0, there is very likely going to be a real GDB
5.1.1 :-)

	Andrew

Re: CVS versions of gdb have same number as stable version.

[Stan Shebs]

Elena Zannoni wrote:
> 
> Let's look at the history:
> 
> 1999-04-09  Jim Blandy  <jimb@zwingli.cygnus.com>
> 
>         * GDB 4.18 released.
>         * Makefile.in (VERSION): Bump to 4.18.1.
> 
> [...]

In retrospect, this hasn't been a great choice, because of the
potential for confusion with real releases.  It's not been too
much of a problem in practice, compared to GCC, because people
don't tend to pick up as many prerelease GDB versions (because
it's perfect already, of course. :-) ).  GDB has also tended
not to have too many point releases.

So for consistency with other projects, I'd favor calling it 5.0.90
now, and 5.1.90 right after the next release, and to update an
appended date every day - that has been very handy for GCC.

Stan

Re: CVS versions of gdb have same number as stable version.

[Christopher Faylor]

On Fri, Feb 16, 2001 at 01:33:02PM -0800, Stan Shebs wrote:
>Elena Zannoni wrote:
>> 
>> Let's look at the history:
>> 
>> 1999-04-09  Jim Blandy  <jimb@zwingli.cygnus.com>
>> 
>>         * GDB 4.18 released.
>>         * Makefile.in (VERSION): Bump to 4.18.1.
>> 
>> [...]
>
>In retrospect, this hasn't been a great choice, because of the
>potential for confusion with real releases.  It's not been too
>much of a problem in practice, compared to GCC, because people
>don't tend to pick up as many prerelease GDB versions (because
>it's perfect already, of course. :-) ).  GDB has also tended
>not to have too many point releases.
>
>So for consistency with other projects, I'd favor calling it 5.0.90
>now, and 5.1.90 right after the next release, and to update an
>appended date every day - that has been very handy for GCC.

I like this idea.  The gcc group has just established an account on
gcc.gnu.org for handling administrative stuff like this.

If necessary, we could set up a gdb administrative account which
just handled regular cron'able tasks like this, too.

cgf

Re: CVS versions of gdb have same number as stable version.

[Andrew Cagney]

Christopher Faylor wrote:

> >So for consistency with other projects, I'd favor calling it 5.0.90
> >now, and 5.1.90 right after the next release, and to update an
> >appended date every day - that has been very handy for GCC.

5.1.0.90 :-)

> I like this idea.  The gcc group has just established an account on
> gcc.gnu.org for handling administrative stuff like this.

There must be a better way of doing this other than filling
gdb/Makefile.in,v up with dummy CVS entries.  Is there a way that CVS
can edit the file on the way out?

If nothing else, a separate file (version.h :-) and put the information
in there.

	Andrew

Re: CVS versions of gdb have same number as stable version.

[Andrew Cagney]

> No, I meant gdb snapshots.  I don't know how GDB snapshots are made,
> but my local GDB repository, which was last sync'd with the 20010108
> snapshot has VERSION=20010108 in gdb/Makefile.in.

Just FYI, a magic shell script does roughly the following:

	cvs co -D 2001-01-08-gmt gdb
	ed src/gdb/Makefile.in
	s/VERSION = .*/VERSION = NNNNNN/
	wq

It is magic because the master copy sits on my local disk outside of
revision control :-(

	Andrew

Re: CVS versions of gdb have same number as stable version.

[Michael Elizabeth Chastain]

Hi J. T.,

> No, I meant gdb snapshots.

My error.  I'm confusing "CVS" with snapshots.  I will download a bunch
of snapshots and have a look at them.

> Note that's not exactly what I said.  I think it is a good idea for a bit
> of brainstorming to ensure that the problem is well understood, decisions 
> are not clear cut, etc.

I *did* that.

  From chastain Fri Feb 16 08:07:18 2001
  To: gdb@sources.redhat.com
  Subject: CVS versions of gdb have same number as stable version.
  ...
  This bothers me.  I've filed a PR about it.
  Can we please use something other than "5.0" for CVS gdb, such as
  "5.1-experimental-$(DATE)", or even just "5.1-experimental"?

  From: Andrew Cagney <ac131313@cygnus.com>
  Date: Fri, 16 Feb 2001 11:34:25 -0500
  Subject: Re: CVS versions of gdb have same number as stable version.
  Why not fix it?  I'm sure you're sufficiently expert in CVS to figure
  out the magic we need to add to change that line.
  ...
  As for snapshots, they already get a time stamp.

[Look, you can see me being stupid about the snapshot timestamps, ouch].

I start by asking for a discussion, and I get "Why not fix it?"
So I fix it, test it, submit a patch, and now I get a discussion.

> None of the above?  

OK.  "5.1-experimental" is not approved, and I'm out of time.  I've
changed the responsible person back to "unassigned" and the state back
to "open".

Michael

Re: CVS versions of gdb have same number as stable version.

[Andrew Cagney]

> OK.  "5.1-experimental" is not approved, and I'm out of time.  I've
> changed the responsible person back to "unassigned" and the state back
> to "open".

Just FYI.  There is an additional step.

Once a discussion has died down (on the internet, everything takes at
least a week), I'll go back over all the e-mails and determine if I
think the issue needs to be followed through.  If I think it does, I'll
then look to investing some of my own time in the problem and (try to)
ensure resolution.

enjoy,
	Andrew

Re: CVS versions of gdb have same number as stable version.

[Michael Elizabeth Chastain]

Andrew Cagney suggests:

>   trunk: gdb-5.1-20054705
>   5.1 branch: gdb-5.0.99, gdb-5.1 (tag), gdb-5.1.0.90, ...

Anything that is not "5.0" works for me.

I like having both a version number and a date in it.  I would also
like "-cvs" for versions built out of CVS pulls (as opposed to
releases and snapshots).

> So again, to restart this discussion .... :-)  Comments?

If the discussion comes to a conclusion, it would be helpful to record
the conclusion in PR gdb/22 as a spec for someone to do the work.

My two cents,

Michael

Re: CVS versions of gdb have same number as stable version.

[Michael Elizabeth Chastain]

It looks fixed to me.

Do you want to close the PR, or do you want me to close it?

Michael

Re: CVS versions of gdb have same number as stable version.

[Andrew Cagney]

I'll close the PR.  Er actually I'll make my self close the PR.  I need 
to start using PRMS.

	Andrew