Thread: v7.3.1 Bundled and Released ...

v7.3.1 Bundled and Released ...

From
"Marc G. Fournier"
Date:
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.




Re: v7.3.1 Bundled and Released ...

From
Greg Copeland
Date:
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


Re: [GENERAL] v7.3.1 Bundled and Released ...

From
Bruce Momjian
Date:
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

Re: v7.3.1 Bundled and Released ...

From
Lamar Owen
Date:
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


Re: [GENERAL] v7.3.1 Bundled and Released ...

From
Greg Copeland
Date:
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


Re: [GENERAL] v7.3.1 Bundled and Released ...

From
Peter Eisentraut
Date:
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



Re: [GENERAL] v7.3.1 Bundled and Released ...

From
Dan Langille
Date:
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.



Re: [GENERAL] v7.3.1 Bundled and Released ...

From
Tom Lane
Date:
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


Re: [GENERAL] v7.3.1 Bundled and Released ...

From
Greg Copeland
Date:
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



Re: [GENERAL] v7.3.1 Bundled and Released ...

From
"Dan Langille"
Date:
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/



Re: [GENERAL] v7.3.1 Bundled and Released ...

From
"Dan Langille"
Date:
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/



Re: [GENERAL] v7.3.1 Bundled and Released ...

From
"Marc G. Fournier"
Date:
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 ...


Re: [GENERAL] v7.3.1 Bundled and Released ...

From
Larry Rosenman
Date:

--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





Re: [GENERAL] v7.3.1 Bundled and Released ...

From
Tom Lane
Date:
"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


Re: [GENERAL] v7.3.1 Bundled and Released ...

From
Giles Lean
Date:
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




Re: [GENERAL] v7.3.1 Bundled and Released ...

From
Dan Langille
Date:
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.



Re: [GENERAL] v7.3.1 Bundled and Released ...

From
Greg Copeland
Date:
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



Re: [GENERAL] v7.3.1 Bundled and Released ...

From
greg@turnstep.com
Date:
-----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-----