Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jbf0i-0003FI-2k for pljava-dev@arkaria.postgresql.org; Thu, 21 May 2020 06:48:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jbf0g-0006VH-Sn for pljava-dev@arkaria.postgresql.org; Thu, 21 May 2020 06:48:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jbf0g-0006VA-NO for pljava-dev@lists.postgresql.org; Thu, 21 May 2020 06:48:54 +0000 Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jbf0e-0006J4-1O for pljava-dev@lists.postgresql.org; Thu, 21 May 2020 06:48:54 +0000 Received: by mail-ej1-x62c.google.com with SMTP id l21so7534770eji.4 for ; Wed, 20 May 2020 23:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mqctnSnwRcBwi2ipj6+u7JCg0RBhTu61PLv4Q8d7N4I=; b=qPoLUAY3g6+w9RzzQ/G/P2/+AR5onNdBF0emtsj+E0NpbJV0bxnp93lxLXF8IKP9zP BDbrJ2dLwsQs12dXpe1plZLRz8cShvgLee0cJkZawwnIFaw1pL14QsX0nmZL9SW8mBdr XggAYC633GEsXO17dR2pnfrIF2oDiTlRZT/IigRBo52z0D/hkeBlWYY2vD/v6JVS55fP HdhX0HNEWq34fIJPOvv3Iu0EQdQas7c/Bm7XKPnYoiWo0KUtOm51V182H/XBYgzmXh56 +zMX1/IDG9VLNDootpdgLzGGTrTOoZbBSTRmD2lg1VLmmaP0W0UFVCyKX/xGIrfw1G6s 1WXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mqctnSnwRcBwi2ipj6+u7JCg0RBhTu61PLv4Q8d7N4I=; b=l9L8PTD108KuC+0cTGG53SY6xOSDXGljSwxnExQ6LkBBFL5+vZs7znTDKtrSXuISHz XQTouT3I6qcB4lenyL59dYTYo0B8YlP+W3D2dklXT5+4F0pKIiLm08P7bkhC2D11mPon nxVuu6ITHSQ0E2S/MtHBOiDvQMDB29TWjNKFxwb1YAJjBgtilyBRGnODkbcaHIHiSdCA zbs83GyrGxyXGhjLJpkhRzsaYlcAW9sDU9ehbh0dyCCzw6wXr/Vuk84YxT4A+XIE9UFx p2lrVgPyk09dVwocmr60ttYqUeuXntAIXaeLq/dxglGiFbQOT+YA5lTH6wfcAvmlw6M+ sb0A== X-Gm-Message-State: AOAM531C47xThVL/BYf5B6ZXFig6hpvV9gZhDCJ+oR1svKeQv8hfvnF9 1SkyjYSJCjL07FxDydNApClDATQ63IiuHInHhXbKD+w9 X-Google-Smtp-Source: ABdhPJyxsiR/ZuBkmbNV3Lcohm08vHsGq6rNAEh+Guc24h7bDF8NHJf3s5BtfnPY2LZ3dz/enFKXWVxwHRLHY7EB7Qw= X-Received: by 2002:a17:906:14d3:: with SMTP id y19mr2215839ejc.466.1590043731018; Wed, 20 May 2020 23:48:51 -0700 (PDT) MIME-Version: 1.0 References: <5EC17E17.7070002@anastigmatix.net> In-Reply-To: <5EC17E17.7070002@anastigmatix.net> From: Kartik Ohri Date: Thu, 21 May 2020 12:18:40 +0530 Message-ID: Subject: Re: Starting build-system work (Windows/Mac users please speak up) To: Chapman Flack Cc: pljava-dev@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000c3c94205a622e71e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000c3c94205a622e71e Content-Type: text/plain; charset="UTF-8" > > == PostgreSQL versions to build for > > Also, the newer branch targets a narrower range of PostgreSQL versions. > The obvious starting point would be the versions currently shown as > 'supported' in the PostgreSQL versioning policy: > > https://www.postgresql.org/support/versioning/ i.e., 12 back to 9.5. > > The branch may build successfully for a couple of versions before 9.5. > I know the 'validator' PR knocked out pre-9.0 versions. When it comes > time to announce PL/Java 1.6, we might choose to say it works back > to PG 9.4, 9.3, or 9.2, if it works for those releases without extra fuss. > > 9.2 is a good stopping place, because the REL1_5_STABLE installation docs > have an extra section for installing on pre-9.2 versions, and that could > go away. > Should I add checks for a PostgreSQL version from each major version or just for one from the latest major version and the oldest version supported ? Like just test with 9.5 and 12.x . Same question with Java versions. Is testing with Java 9 and Java 14 (the latest java release) is enough ? Or each of java versions in between Java 9 and 14 should be tested as well. --000000000000c3c94205a622e71e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=3D=3D PostgreSQL versions to build for

Also, the newer branch targets a narrower range of PostgreSQL versions.
The obvious starting point would be the versions currently shown as
'supported' in the PostgreSQL versioning policy:

https://www.postgresql.org/support/versioning/=C2= =A0 i.e., 12 back to 9.5.

The branch may build successfully for a couple of versions before 9.5.
I know the 'validator' PR knocked out pre-9.0 versions. When it com= es
time to announce PL/Java 1.6, we might choose to say it works back
to PG 9.4, 9.3, or 9.2, if it works for those releases without extra fuss.<= br>
9.2 is a good stopping place, because the REL1_5_STABLE installation docs have an extra section for installing on pre-9.2 versions, and that could go away.

Should I add checks for a Post= greSQL version from each major version or just for one from the latest majo= r version and the oldest version supported ? Like just test with 9.5 and 12= .x . Same question with Java versions. Is testing with Java 9 and Java 14 (= the latest java release) is enough ? Or each of java versions in between Ja= va 9 and 14 should be tested as well.
=C2=A0
--000000000000c3c94205a622e71e--