[release/branch] Set GDB version number to str 7.9.

  > In preparation for the GDB 7.9 release, I am about to push
> this commit...
> 
> gdb/ChangeLog:
> 
> 	* version.in: Set GDB version number to str 7.9.
[...]
> diff --git a/gdb/version.in b/gdb/version.in
> index 8c98182..2d982e4 100644
> --- a/gdb/version.in
> +++ b/gdb/version.in
> @@ -1 +1 @@
> -7.8.90.DATE-cvs
> +str 7.9

For those who were actually paying attention (not me), there is
an obvious mistake in the version number.

For my penance, I'll explain how it happened:
I use a set of python scripts to do most of the grunt work.
The purpose is to make sure everything gets done without anything
falling through the cracks; and by doing most of it automatically,
I reduce the changes for errors. The scripts are configured via
a small yaml file. Normally, I'd just put write the version number
and done, but "7.9" looking like a float, I have to say "!!str 7.9"
instead. Except that I forgot the two leading "!!".

The scripts show me the diff before pushing, and asks me to confirm.
But I was sleeping at the wheel. Fortunately, I caught it slightly
later on. Attached is the patch that fixes the issue.

gdb/ChangeLog:

        * version.in: Change to "7.9" instead of "str 7.9".
  

On Thu, Feb 19, 2015 at 04:23:19PM +0400, Joel Brobecker wrote:
> > In preparation for the GDB 7.9 release, I am about to push
> > this commit...
> > 
> > gdb/ChangeLog:
> > 
> > 	* version.in: Set GDB version number to str 7.9.
> [...]
> > diff --git a/gdb/version.in b/gdb/version.in
> > index 8c98182..2d982e4 100644
> > --- a/gdb/version.in
> > +++ b/gdb/version.in
> > @@ -1 +1 @@
> > -7.8.90.DATE-cvs
> > +str 7.9
> 
> For those who were actually paying attention (not me), there is
> an obvious mistake in the version number.
[...]
> But I was sleeping at the wheel. Fortunately, I caught it slightly
> later on. Attached is the patch that fixes the issue.

Humpf, I am realizing now that this was not soon enough:
I already pushed the gdb-7.9-release tag, and that tag
points to the first commit, and therefore has the wrong
version number in it.

The normal thing to do in those cases is to just accept the mistake
and create a new tag, tagging the correct commit. I find it so very
very ugly, but if I were to fix the tag, anyone having pulled from
sourceware would already have the "wrong" one, and would later on
have to delete the tag from their repository before they can get
the new one.

I'm not sure what to do:
  1. Create a new tag  (Eg: "gdb-7.9.0-release")
  2. Just re-do the tag (aka "the insane way")
  3. Leave things as is
  4. Abandon "7.9" and release "7.9.1" instead...

I am leaning towards option 4...

Thoughts?
  

> Date: Thu, 19 Feb 2015 16:40:10 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> 
> I'm not sure what to do:
>   1. Create a new tag  (Eg: "gdb-7.9.0-release")
>   2. Just re-do the tag (aka "the insane way")
>   3. Leave things as is
>   4. Abandon "7.9" and release "7.9.1" instead...
> 
> I am leaning towards option 4...

Wouldn't it be even more confusing to have 7.9.1 without 7.9?

I'd say creating a new tag is good enough.
  

On 02/19/2015 12:45 PM, Eli Zaretskii wrote:
>> Date: Thu, 19 Feb 2015 16:40:10 +0400
>> From: Joel Brobecker <brobecker@adacore.com>
>>
>> I'm not sure what to do:
>>   1. Create a new tag  (Eg: "gdb-7.9.0-release")
>>   2. Just re-do the tag (aka "the insane way")
>>   3. Leave things as is
>>   4. Abandon "7.9" and release "7.9.1" instead...
>>
>> I am leaning towards option 4...
> 
> Wouldn't it be even more confusing to have 7.9.1 without 7.9?
> 
> I'd say creating a new tag is good enough.

Agreed.

To minimize confusion, you can also delete the bad tag, and
then most people won't ever see it.  Those who managed to
pull in the bad tag in can get rid of it with
e.g., "git pull --prune --tags".

Thanks,
Pedro Alves
  

> > Wouldn't it be even more confusing to have 7.9.1 without 7.9?
> > 
> > I'd say creating a new tag is good enough.
> 
> Agreed.
> 
> To minimize confusion, you can also delete the bad tag, and
> then most people won't ever see it.  Those who managed to
> pull in the bad tag in can get rid of it with
> e.g., "git pull --prune --tags".

I would have documented it in both NEWS and website, but
deleting the tag is indeed a good idea. I will create a new one
momentarily.

Thanks for your feedback.