Re: perltidy version - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: perltidy version
Date
Msg-id CABUevEwELTPBhwH9s74HxE3JwRAhEn2kWRMsavf+_AN3pATMUA@mail.gmail.com
Whole thread Raw
In response to Re: perltidy version  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: perltidy version  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers


On Mon, Mar 5, 2018 at 2:53 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Magnus Hagander wrote:

> For example, Debian ships with 20140328, which produces the attached diff.
> I'm not sure if we want to go to whatever is a "common version on most
> platforms" today, or just "whatever is latest" if we do upgrade. AFAICT
> RHEL 7 seems to be on 20121207, RHEL 6 on 20090616. And in Ubuntu, 14.04
> has 20120701, 16.04 has 20140328, and current devel has 20140328. In
> general there seems to be very little overlap there, except Debian and
> Ubuntu covers the same versions.

here's the changelog
https://metacpan.org/source/SHANCOCK/Perl-Tidy-20180220/CHANGES

The wikipedia page claims that the latest stable release is 20160302,
but that seems to be just because the page is out of date (last update
is before the following 2017-05 release)

It's hard to form an opinion based on this.  I don't think picking one
because of its availability in some distribution is useful, since almost
everyone is going to have to download a custom one anyway, whichever
distribution we pick -- unless it's mine, of course, hah.

I think we should just pick some recent one and use it for X years; use
that one for all backbranches.  I propose X=3.  I propose 20170521
(newer ones seem to cater for stuff that I think we mostly don't use).

20140328 seems to cover *most* versions. Another argument for that one would be it's the one that we have on Borka, which is where we build the official release tarballs, so we can use that as a stable fallback.

Those are both fairly weak arguments though. As long as we have good instructions for how to make a local install of it that doesn't affect the rest of the system, then that should not matter. And we need such instructions anyway, since it won't be on every distribution. 


--

pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: [HACKERS] Creating backup history files for backups taken fromstandbys
Next
From: Emre Hasegeli
Date:
Subject: Re: constraint exclusion and nulls in IN (..) clause