Re: perltidy version

Поиск
Список
Период
Сортировка
От Tels
Тема Re: perltidy version
Дата
Msg-id 95e152a355054e82dc6e6deeb1ce0488.squirrel@sm.webmail.pair.com
обсуждение исходный текст
Ответ на Re: perltidy version  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: perltidy version  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Moin,

On Wed, April 25, 2018 12:35 pm, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> On Mon, Apr 23, 2018 at 12:40:00PM -0400, Tom Lane wrote:
>>> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>>>> I still vote we use 20170521 which is recent enough that we won't have
>>>> to change it in a few years.
>
>> That's the version available on Debian sid, so from the prospective of
>> any Debian user this is a handy version to use when sending patches:
>> perltidy/unstable,now 20170521-1 all [installed]
>
> I'm not hearing any objections or counterproposals, so let's go with
> that version.
>
>>>> I further vote that we change the URL in pgindent/README from
>>>> sourceforge to metacpan.org,
>>>> https://metacpan.org/pod/distribution/Perl-Tidy/lib/Perl/Tidy.pod
>
> Agreed on pointing to cpan, but that page is pretty confusing if you're
> looking for a non-bleeding-edge version.  I suggest linking to
>
> https://cpan.metacpan.org/authors/id/S/SH/SHANCOCK/
>
> which presents a handy directory listing.

Linking to the author directory can be pretty confusing, because if a new
(co-)-maintainer releases something, it will end up not in this directory.

But it is possible to point to the specific version PG needs like so:

http://search.cpan.org/~shancock/Perl-Tidy-20170521/

That way visitor see the right version, but also have all the other data
and see all other (still existing) versions, if they want.

If that page is "more confusing" than a directory listing where you have
to pick the right file, or not, is of course debatable.

Regards,

Tels


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Corrupted btree index on HEAD because of covering indexes
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [sqlsmith] Failed assertion in create_gather_path