From: Tom Lane <tgl@sss.pgh.pa.us>
To: =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org>
cc: "Euler Taveira" <euler@eulerto.com>,
 "Peter Smith" <smithpb2250@gmail.com>,
        "Michael Paquier" <michael@paquier.xyz>,
        "PostgreSQL Hackers" <pgsql-hackers@lists.postgresql.org>,
        "Peter Eisentraut" <peter@eisentraut.org>,
        "Euler Taveira" <euler.taveira@enterprisedb.com>
Subject: Re: pg_createsubscriber TAP test wrapping makes command options hard
 to read.
In-reply-to: <87ikq93qqa.fsf@wibble.ilmari.org>
References: 
 <CAHut+PvfaUZQR3rEnj-Dcg_6713Wu4yRdd-yZkkC9NVsARht8A@mail.gmail.com>
 <556792.1733967676@sss.pgh.pa.us>
 <CAHut+Ps6Q+i_3xS6H7ybw3-hx9+2QOuneTJwHArxqxFnKX5+4g@mail.gmail.com>
 <564915.1733971586@sss.pgh.pa.us>
 <CAHut+PvFGytgJT+K_e2x+uWKuVYCBR3HNaNtPKYEkO3YxAwZvw@mail.gmail.com>
 <Z1peKSb8roiDNgRj@paquier.xyz>
 <CAHut+PvYsVhF5k-mYHVEFdpijdgkYRtoeWVxdspxio0ePRpkug@mail.gmail.com>
 <87pllx5cqn.fsf@wibble.ilmari.org> <87msh159c3.fsf@wibble.ilmari.org>
 <CAHut+Ptmusd=7SdZ-n0=fu-Y8ut=UaK9nU4Cqk01wxOmio9nkA@mail.gmail.com>
 <87o70143p6.fsf@wibble.ilmari.org>
 <3b6b2595-9822-4e4f-91ee-b6a44dc4b542@app.fastmail.com>
 <3238498.1737413396@sss.pgh.pa.us>
 <0f90c5bd-e71f-49ec-ab80-ba2008be5c37@app.fastmail.com>
 <87ikq93qqa.fsf@wibble.ilmari.org>
Comments: In-reply-to =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?=
 <ilmari@ilmari.org>
	message dated "Tue, 21 Jan 2025 01:22:53 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3259116.1737424962.1@sss.pgh.pa.us>
Date: Mon, 20 Jan 2025 21:02:42 -0500
Message-ID: <3259117.1737424962@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3259117.1737424962%40sss.pgh.pa.us>
Precedence: bulk

=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org> writes:
> All in all, this makes me +0.5 to bumping the required Perl::Tidy
> version, and +0.5 on (at least considering) bumping it to the latest
> version before the pre-release-branch pgperltidy run.

Nah, I'm pretty much -1 on bumping our perltidy version frequently.
That imposes costs on every developer who wants to track it.
It's unlikely that anyone will be on a platform that updates it
exactly when we decide to change, so most of us are going to be
using hand-installed copies that will have to be hand-updated
whenever we change versions.

As a data point, we were using 20170521 for five years before
adopting 20230309, and 20090616 for seven years before that,
which is as far back as I can trace any definitive info about
which version was being used.  Every five years or so sounds
like a sane cadence to me, in terms of developer overhead
versus likely formatting improvements.

(Of course, if a new version comes out that is way better than
what we're using, I could be persuaded that it's worth changing.
But from what you're showing here, that hasn't happened yet.)

			regards, tom lane