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/>
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 |