v7.3.1 Bundled and Released ...

On Sun, 2002-12-22 at 13:12, Marc G. Fournier wrote:

Last night, we packaged up v7.3.1 of PostgreSQL, our latest stable
release.

Purely meant to be a bug fix release, this one does have one major change,
in that the major number of the libpq library was increased, which means
that everyone is encouraged to recompile their clients along with this
upgrade.

This release can be found on all the mirrors, and on the root ftp server,
under:

ftp://ftp.postgresql.org/pub/source/v7.3.1

Please report all bugs to pgsql-bugs@postgresql.org.

Hmm. For some reason I'm not seeing a 7.3.1 tag in CVS. Do you guys do
something else for sub-releases? Case in point:
cvs [server aborted]: no such tag REL7_3_1_STABLE
It's still early here so I may be suffering from early morning brain
rot. ;)

Regards,

Greg

--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting

Greg Copeland wrote:

On Sun, 2002-12-22 at 13:12, Marc G. Fournier wrote:

Last night, we packaged up v7.3.1 of PostgreSQL, our latest stable
release.

Purely meant to be a bug fix release, this one does have one major change,
in that the major number of the libpq library was increased, which means
that everyone is encouraged to recompile their clients along with this
upgrade.

This release can be found on all the mirrors, and on the root ftp server,
under:

ftp://ftp.postgresql.org/pub/source/v7.3.1

Please report all bugs to pgsql-bugs@postgresql.org.

Hmm. For some reason I'm not seeing a 7.3.1 tag in CVS. Do you guys do
something else for sub-releases? Case in point:
cvs [server aborted]: no such tag REL7_3_1_STABLE
It's still early here so I may be suffering from early morning brain
rot. ;)

There should be a 7.3.1 tag, but you can use the 7_3 branch to pull
7.3.1. Of course, that will shift as we patch for 7.3.2.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Sunday 22 December 2002 14:12, Marc G. Fournier wrote:

Last night, we packaged up v7.3.1 of PostgreSQL, our latest stable
release.

RPMs are available for RedHat8 + tcl8.4.1 at
ftp://ftp.postgresql.org/pub/binary/v7.3.1/RPMS (once mirrors propagate it
will be at the mirrors)

Yes, Red Hat 8.0 _+_ tcl8.4.1. If you wish to use the pl subpackage without
pl/tcl, you need to add --nodeps to the rpm command line when installing the
pl subpackage. The postgresql-tcl subpackage was built against tcl 8.4.1 --
Red Hat 8 ships with an old tcl (8.3.3) which is not even installed by
default. If this is too much of a problem for people, please let me know,
and I'l rebuild for Red Hat 8 without any tcl support, or with the older tcl
support. Otherwise obtain tcl 8.4.1. I have to have it installed here for
work purposes. This is the only exception to the 'pristine Red Hat install'
I have made in a very long time. Rebuilding from source RPM will require an
installed tcl of some version.

Source RPMS in SRPMS, Red Hat 8 binaries in redhat-8.0

If installing the contrib subpackage, you must use --nodeps due to a broken
dependency upon the now removed postgresql-perl subpackage. There will be
soon a postgresql-perl RPM -- I have to get the new gborg code and build it,
I guess.

Changelog since 7.3-2:
* Mon Dec 23 2002 Lamar Owen <lamar.owen@ramifordistat.net>
- 7.3.1-1PGDG
- Fix dependency order for test and pl subpackages.
- Fixed a bug in the initscript for echo_success
- Fixed the bug in .bashprofile (argh).

(quick note: lamar.owen@ramifordistat.net does work. I typically post from
lamar.owen@wgcr.org; both addresses come to me....)
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Just a reminder, there still doesn't appear to be a 7.3.1 tag.

This is from the "HISTORY" file.

symbolic names:
REL7_3_STABLE: 1.182.0.2
REL7_2_3: 1.153.2.8
REL7_2_STABLE: 1.153.0.2
REL7_2: 1.153

Notice 7.3 stable but nothing about 7.3.x! I also see a 7.2.3, etc.,
just as one would expect but nothing about 7.3 dot releases.

I'm still getting, "cvs [server aborted]: no such tag REL7_3_1_STABLE".
Something overlooked here?

Regards,

Greg Copeland

On Mon, 2002-12-23 at 09:57, Bruce Momjian wrote:

Greg Copeland wrote:

On Sun, 2002-12-22 at 13:12, Marc G. Fournier wrote:

Last night, we packaged up v7.3.1 of PostgreSQL, our latest stable
release.

Purely meant to be a bug fix release, this one does have one major change,
in that the major number of the libpq library was increased, which means
that everyone is encouraged to recompile their clients along with this
upgrade.

This release can be found on all the mirrors, and on the root ftp server,
under:

ftp://ftp.postgresql.org/pub/source/v7.3.1

Please report all bugs to pgsql-bugs@postgresql.org.

Hmm. For some reason I'm not seeing a 7.3.1 tag in CVS. Do you guys do
something else for sub-releases? Case in point:
cvs [server aborted]: no such tag REL7_3_1_STABLE
It's still early here so I may be suffering from early morning brain
rot. ;)

There should be a 7.3.1 tag, but you can use the 7_3 branch to pull
7.3.1. Of course, that will shift as we patch for 7.3.2.

--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting

Greg Copeland writes:

Just a reminder, there still doesn't appear to be a 7.3.1 tag.

There is a long tradition of systematically failing to tag releases in
this project. Don't expect it to improve.

--
Peter Eisentraut peter_e@gmx.net

On Sat, 4 Jan 2003, Peter Eisentraut wrote:

Greg Copeland writes:

Just a reminder, there still doesn't appear to be a 7.3.1 tag.

There is a long tradition of systematically failing to tag releases in
this project. Don't expect it to improve.

It was I who suggested that a release team would be a good idea. I think
that was soundly rejected. I still think it's a good idea. If only to
ensure that things are properly tagged, the right annoucements go out at
the right times, that a code freeze goes into effect, etc. These concepts
are not new. A release is an important step in the life cycle.

I volunteered to document the release procedure as it resides only within
lore and a couple of heads. I have yet to start.

Dan Langille <dan@langille.org> writes:

On Sat, 4 Jan 2003, Peter Eisentraut wrote:

There is a long tradition of systematically failing to tag releases in
this project. Don't expect it to improve.

It was I who suggested that a release team would be a good idea.

We *have* a release team. Your problem is that Marc, who is the man who
would need to do this, doesn't appear to consider it an important thing
to do. Try to convince him to put it on his checklist.

regards, tom lane

On Sat, 2003-01-04 at 04:27, Peter Eisentraut wrote:

Greg Copeland writes:

Just a reminder, there still doesn't appear to be a 7.3.1 tag.

There is a long tradition of systematically failing to tag releases in
this project. Don't expect it to improve.

Well, I thought I remembered from the "release team" thread that it was
said there was a "punch list" of things that are done prior to actually
releasing. If not, it certainly seems like we need one. If there is
one, tagging absolutely needs to be on it. If we have one and this is
already on the list, seems we need to be eating our own food. ;)

--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting

msg resent because I incorrectly copied/pasted some addresses.
Sorry.

On 4 Jan 2003 at 11:08, Tom Lane wrote:

Dan Langille <dan@langille.org> writes:

On Sat, 4 Jan 2003, Peter Eisentraut wrote:

There is a long tradition of systematically failing to tag releases
in this project. Don't expect it to improve.

It was I who suggested that a release team would be a good idea.

We *have* a release team.

I have a suggestion. Let us document who is the release team and who
is responsible for each step of the release. Perhaps that is the
problem: a lack of process.

I'll add that to my list of things I've promised to do.
--
Dan Langille : http://www.langille.org/

msg resent because I incorrectly copied/pasted some addresses. Sorry.

On 4 Jan 2003 at 11:08, Tom Lane wrote:

Dan Langille <dan@langille.org> writes:

On Sat, 4 Jan 2003, Peter Eisentraut wrote:

There is a long tradition of systematically failing to tag releases
in this project. Don't expect it to improve.

It was I who suggested that a release team would be a good idea.

We *have* a release team. Your problem is that Marc, who is the man
who would need to do this, doesn't appear to consider it an important
thing to do. Try to convince him to put it on his checklist.

Marc? Is this true? You don't consider it important to tag the
release? I'm quite sure that's not the case and that Marc does
consider it important. It's just something which he forgot to do.

A recent post by Greg Copeland implies this item is on his checklist.

IMHO, it is vital that the tree is properly tagged for each release.
AFAIK, a tag can be laid with with respect to timestamp value. So
why don't we just do it?
--
Dan Langille : http://www.langille.org/

On Sat, 4 Jan 2003, Tom Lane wrote:

Dan Langille <dan@langille.org> writes:

On Sat, 4 Jan 2003, Peter Eisentraut wrote:

There is a long tradition of systematically failing to tag releases in
this project. Don't expect it to improve.

It was I who suggested that a release team would be a good idea.

We *have* a release team. Your problem is that Marc, who is the man who
would need to do this, doesn't appear to consider it an important thing
to do. Try to convince him to put it on his checklist.

I never considered tag'ng for minor releases as having any importance,
since the tarball's themselves provide the 'tag' ... branches give us the
ability to back-patch, but tag's don't provide us anything ... do they?

That said, I can back-tag the whole source tree for past releases if ppl
do think it is important, its just a matter of knowing the 'timestamp' to
base it on, which I can do based on the dates of the tar files ...

Its not like tag'ng is hard to do ...

--On Saturday, January 04, 2003 21:04:32 -0400 "Marc G. Fournier"
<scrappy@hub.org> wrote:

On Sat, 4 Jan 2003, Tom Lane wrote:

Dan Langille <dan@langille.org> writes:

On Sat, 4 Jan 2003, Peter Eisentraut wrote:

There is a long tradition of systematically failing to tag releases in
this project. Don't expect it to improve.

It was I who suggested that a release team would be a good idea.

We *have* a release team. Your problem is that Marc, who is the man who
would need to do this, doesn't appear to consider it an important thing
to do. Try to convince him to put it on his checklist.

I never considered tag'ng for minor releases as having any importance,
since the tarball's themselves provide the 'tag' ... branches give us the
ability to back-patch, but tag's don't provide us anything ... do they?

That said, I can back-tag the whole source tree for past releases if ppl
do think it is important, its just a matter of knowing the 'timestamp' to
base it on, which I can do based on the dates of the tar files ...

It's useful for those using the CVS files to RECREATE a version based on
the TAG
to checkout something (without pulling the whole tarball).

LER

Its not like tag'ng is hard to do ...

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

"Marc G. Fournier" <scrappy@hub.org> writes:

I never considered tag'ng for minor releases as having any importance,
since the tarball's themselves provide the 'tag' ... branches give us the
ability to back-patch, but tag's don't provide us anything ... do they?

Well, a tag makes it feasible for someone else to recreate the tarball,
given access to the CVS server. Dunno how important that is in the real
world --- but I have seen requests before for us to tag release points.

Any other arguments out there?

regards, tom lane

Tom Lane wrote:

Any other arguments out there?

Per-release tags make it easier to see quickly if some code has
changed in -current or not. As the CVS tree is available via anoymous
CVS (I think?), CVSup, and via the web so there are many potential
users who are not active developers and who probably run releases
rather than -current.

Regards,

Giles

On Sat, 4 Jan 2003, Tom Lane wrote:

"Marc G. Fournier" <scrappy@hub.org> writes:

I never considered tag'ng for minor releases as having any importance,
since the tarball's themselves provide the 'tag' ... branches give us the
ability to back-patch, but tag's don't provide us anything ... do they?

Well, a tag makes it feasible for someone else to recreate the tarball,
given access to the CVS server. Dunno how important that is in the real
world --- but I have seen requests before for us to tag release points.

FWIW, in the real world, a release doesn't happen if it's not taqged.

On Sun, 2003-01-05 at 06:41, Dan Langille wrote:

On Sat, 4 Jan 2003, Tom Lane wrote:

"Marc G. Fournier" <scrappy@hub.org> writes:

I never considered tag'ng for minor releases as having any importance,
since the tarball's themselves provide the 'tag' ... branches give us the
ability to back-patch, but tag's don't provide us anything ... do they?

Well, a tag makes it feasible for someone else to recreate the tarball,
given access to the CVS server. Dunno how important that is in the real
world --- but I have seen requests before for us to tag release points.

FWIW, in the real world, a release doesn't happen if it's not taqged.

Agreed! Any tarballs, rpms, etc., should be made from the tagged
source. Period. If rpm's are made from a tarball that is made from
tagged source, that's fine. Nonetheless, any official release (major or
minor) should always be made from the resulting tagged source. This
does two things. First, it validates that everything has been properly
tagged. Two, it ensures that there are not any localized files or
changes which might become part of a tarball/release which are not
officially part of the repository.

I can't stress enough that a release should never happen unless source
has been tagged. Releases should ALWAYS be made from a checkout based
on tags.

--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Well, a tag makes it feasible for someone else to recreate the tarball,
given access to the CVS server. Dunno how important that is in the real
world --- but I have seen requests before for us to tag release points.

Any other arguments out there?

FWIW, I use the tags often in some scripts that rely on the output
of 'cvs status -v'. Seeing REL7_3_STABLE at the top of the
"Existing Tags" list is a bit disconcerting when you know that
it's not true. My scripts assume that the latest release should
always be tagged.

Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200208

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iD8DBQE+GE1NvJuQZxSWSsgRAh/1AKCPEKQeQ3OnKzbeSl5DXstnwwiFPQCfQ2mn
KplkOouzodJqZvQNN2tk8Fk=
=OaZY
-----END PGP SIGNATURE-----

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 05 January 2003 01:10
To: Marc G. Fournier
Cc: Dan Langille; Peter Eisentraut; Greg Copeland; Bruce
Momjian; PostgresSQL Hackers Mailing List
Subject: Re: [GENERAL] [HACKERS] v7.3.1 Bundled and Released ...

"Marc G. Fournier" <scrappy@hub.org> writes:

I never considered tag'ng for minor releases as having any

importance,

since the tarball's themselves provide the 'tag' ...

branches give us

the ability to back-patch, but tag's don't provide us

anything ... do

they?

Well, a tag makes it feasible for someone else to recreate
the tarball, given access to the CVS server. Dunno how
important that is in the real world --- but I have seen
requests before for us to tag release points.

Any other arguments out there?

I've often found tags useful when ppl have reported bugs that have
occured between version - A quick way to see the changes that might have
introduced the new bug when browsing though a web interface.

Regards, Dave.