Re: Release versioning inconsistency

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Marti Raudsepp <marti(at)juffo(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Release versioning inconsistency
Date: 2012-06-21 14:17:17
Message-ID: CABUevEw-VuSg2DGup6XGNYkr0QN2-981yckz=jAy+Z13v9ZO3g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 20, 2012 at 5:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On ons, 2012-06-20 at 13:26 +0200, Magnus Hagander wrote:
>>> That might actually be a good idea. We can't really change the way we
>>> named the betas, but it's not too late to consider naming the actual
>>> release as 9.2.0...
>
>> The final release was always going to be called 9.2.0, but naming the
>> beta 9.2.0betaX is wrong.  There was a previous discussion about that
>> particular point.
>
> Yes.  There is no reason to change the naming scheme we have been using
> for years now (at least since version_stamp.pl was invented for 7.4).
> The only problem is that somebody got the name of the directory wrong on
> the FTP server.

If that wasn't clear, then yes, that was me.

I don't recall the reason why using 9.2.0betax was actually wrong - i
realize that's not the name of the version, so thereby the directory
was wrong. But in what way would it be wrong to call the version that?
Given that it would help with sorting. (And yes, this is a very
long-forward question, more about 9.3, since we can't really go back
and change the current filename..)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2012-06-21 14:19:31 Re: Release versioning inconsistency
Previous Message Edmon Begoli 2012-06-21 14:12:55 Reseting undo/redo logs