Thread: STILL LACKING: CVS tag for release 7.2.1
I'm using: 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? Cheers. -- Jack Bates Portland, OR, USA http://www.floatingdoghead.net Got privacy? My PGP key: http://www.floatingdoghead.net/pubkey.txt
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 #