STILL LACKING: CVS tag for release 7.2.1

On Sunday 05 May 2002 02:46 pm, Jack Bates wrote:

CVSROOT=:pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot

Still no tag for 7.2.1.

Could I (again) request that a tag be set for the current public release
of this product?

Why? There is typically a REL tag set for the major, then a REL PATCHES tag
set for the minors as a collective. If you want to track the current stable,
you get the PATCHES tag, if one is set...However, our tags have never been
consistent, unfortunately. We have a right hodgepodge of tags, according to
the web interface (http://developer.postgresql.org/cvsweb.cgi/pgsql/)
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Sun, 5 May 2002, Lamar Owen wrote:

On Sunday 05 May 2002 02:46 pm, Jack Bates wrote:

CVSROOT=:pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot

Still no tag for 7.2.1.

Could I (again) request that a tag be set for the current public release
of this product?

Why? ...

Aside from being a near-universal "best practice", it makes it easier for
someone to analyze whether local patches to 7.2.1 conflict with work that
the team has committed. This makes it easier for patches to be massaged
and submitted to the maintainers successfully even if the patch is not
originally written for CVS head. Not everyone wants to develop on the
bleeding edge all the time. Code that has passed local acceptance testing
needs to be supported carefully at its existing release level, if at all
possible.

There was a tag for the 7.1.2 release, which was my previous baseline. A
bunch of BETAs leading to 7.2 are tagged. Why not the current public
release?

I'm not here to bully and I apologize if my tone irritated. I'm a
seasoned software engineer, and I'm happy to help out a bit in areas where
I am qualified to do so. I submitted a patch last week for an obscure SSL
issue in libpq and I'm looking at enabling, generally, non-blocking client
IO over SSL in that library.

BTW - I _LOVE_ 7.2's non-locking VACUUM ANALYZE - many, many thanks!
Recent murmurings about propogating "deadness" of tuples to reduce index
scan time are quite interesting to me, as is point-in-time recovery.
Even without these features, PostgreSQL works _very_ well and quite
predictably for me. I beat on this DBMS very hard, and I have not been
able to break 7.2[.1] (nor 7.1.2, previously). Real good stuff.

Cheers.

--

Jack Bates
Portland, OR, USA
http://www.floatingdoghead.net

Got privacy?
My PGP key: http://www.floatingdoghead.net/pubkey.txt

<jack@floatingdoghead.net> writes:

Aside from being a near-universal "best practice", it makes it easier for
someone to analyze whether local patches to 7.2.1 conflict with work that
the team has committed.

There is a 7.2 branch, and I would think that the tip of that branch is
generally what you are interested in if you do not want the HEAD tip.

Applying a tag to indicate exactly what state of that branch got
released as 7.2.1 would be good from a historical-documentation
point of view, but I can't see that it has any direct relevance
for either current development or maintenance work.

Of course, the real answer to your question is that Marc Fournier does
that work, and the rest of us long ago gave up trying to get him to be
perfectly consistent in his tagging practices ;-)

regards, tom lane

hi,
can v define our own datatype n use it in PostgreSQL tables?
Shra

Shra wrote:

hi,
can v define our own datatype n use it in PostgreSQL tables?
Shra

u can

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #