Thread: v7.3.1 Bundled and Released ...
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.
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-----