On Fri, Nov 27, 2015 at 2:50 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
> On 27 November 2015 at 12:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> Euler Taveira <euler@timbira.com.br> writes:
>> > On 26-11-2015 14:06, YUriy Zhuravlev wrote:
>> >> I meant that support for older versions of CMake I'll do when will
>> >> implement
>> >> other functions.
>>
>> > I think you don't understand the point: start with the *right* cmake
>> > version because you could have to redo (a lot of) your work or have your
>> > patch rejected because you don't follow our advice.
>>
>> The way Yuriy wants to do it is not necessarily wrong. He might end up
>> with cleaner code if he starts by making a cmake-3 implementation and then
>> figures out how to back-port to cmake-2, rather than starting with the
>> more limited language to begin with.
>>
>> Or maybe not. But I doubt it's open and shut.
>
> One thing to consider: I can't imagine backporting this to all supported
> back branches, it'd be a switch for the next release. Right?
>
> That means he doesn't have to worry about what RH / Debian policy for their
> old versions is. RH isn't going to release PostgreSQL 9.7 or whatever for
> RHEL6, Debian isn't going to release it for Wheezy, etc.
>
> We are. Or rather, the people within the community who perform the thankless
> task of packaging are.
That's not only a problem related to packaging by pgdg maintainers or
the main Linux distributions. I think that you are forgetting people
who actually work on or compile the Postgres code on those platforms,
say because they for example need to perform performance test or
measurements particularly on such platforms based on customer
requirements, one possibility being to test different configure
options like bigger relation file blocks for example. It does not seem
acceptable to me to choose a minimal version of cmake without this
criteria taken into account.
--
Michael