Re: perltidy version

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: perltidy version
Date: 2018-03-05 14:02:07
Message-ID: CABUevEwELTPBhwH9s74HxE3JwRAhEn2kWRMsavf+_AN3pATMUA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 5, 2018 at 2:53 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Emre Hasegeli 2018-03-05 14:04:01 Re: constraint exclusion and nulls in IN (..) clause
Previous Message David Steele 2018-03-05 14:01:23 Re: [HACKERS] Creating backup history files for backups taken from standbys