Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gqzp1-0008FO-VC for pgadmin-hackers@arkaria.postgresql.org; Tue, 05 Feb 2019 12:27:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gqzp0-0003q9-KC for pgadmin-hackers@arkaria.postgresql.org; Tue, 05 Feb 2019 12:27:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gqzp0-0003q1-Eh for pgadmin-hackers@lists.postgresql.org; Tue, 05 Feb 2019 12:27:26 +0000 Received: from mail-pg1-x541.google.com ([2607:f8b0:4864:20::541]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gqzox-0008Eo-1d for pgadmin-hackers@postgresql.org; Tue, 05 Feb 2019 12:27:25 +0000 Received: by mail-pg1-x541.google.com with SMTP id s198so1329375pgs.2 for ; Tue, 05 Feb 2019 04:27:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dtnoKmkv7/v+LnHomumvC+yqVcJZAVpv0PnXqGT4ouY=; b=wVEI/Y2OVaHrAsgwU+FY9TluCAGGLl2C7fIGX46uW/HSxu1D3+h5iDhKJZxj3SEOX+ N03+vjgR8pSmmPdlt97oTE8TMFKJhR9RC+BWqYRc3xiAsrQ1e9BI6TIkr/1BhziR+l1J 8369oyClDeSDLBfwB8wBooWl69kQwvxYXilMaY/9jMg69fivjaXz7y109lierC6YwFmc HrnM6lOrj5jBac6svJcz7J+PGzT7JlBmS0yNhQ4Rwp9xCk1m271Koujt4nCNATmUxCTo RViSpdNMzoL5254EO964eBYMtVWPRfkLx1NQJ5dUG6cHS+biMMCnpK9JYREvjTNv0fjY CdNg== 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=dtnoKmkv7/v+LnHomumvC+yqVcJZAVpv0PnXqGT4ouY=; b=lz6emOwh7mlJNUFsGpBkuor5aBqREKdCJV9yqtXxBu0z0c7U1a9Lsqm/tJxDkCwKLU GGVV5rUmfkmUgztaRejwqHbJKRQKtVEENvIJLgoSHmTc6p0IaKK4kfri0KQDcVo812e9 fhUDsHbLmiqj7c/rwsafd+7BnRFq7L2aNg6jxuR6UgLxc8UMUnnErIoIr58byWxtgdO9 d4mOKaOkUZZ1E/xErDa1uXpk1YkytrS3Su86QVGY0x24DYFt5NODeu5B2kPmJZe3P4GQ nPzf3+bMIZYn50KYINcoZQEmg2mwvIwlE82noXWhRiG3LDz8LggmcmlogLMoOkpnCJNR CQlg== X-Gm-Message-State: AHQUAubxzBmkUWRMiKMLSPxa/TdEwsWLTxMmv1Z+u4QpbWBmvspDpMhM ntfeqMecjGG64pW4JN6PwrtvyaLCKcZH3y5PKcRm6A== X-Google-Smtp-Source: AHgI3IZfeDSBqIVaFONd0wTW4ReMgeWrjifS2gbh97EB0Dnmkcl5LFZ5tURWD04XreiNn1OYa9qRz+FPxG+FdLIqp4o= X-Received: by 2002:a63:554b:: with SMTP id f11mr4469360pgm.37.1549369639247; Tue, 05 Feb 2019 04:27:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Sandeep Thakkar Date: Tue, 5 Feb 2019 17:57:08 +0530 Message-ID: Subject: Re: Packagers: Handling upgrade checks To: Dave Page Cc: Srinu Perabattula , pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000f93bc0058124baac" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000f93bc0058124baac Content-Type: text/plain; charset="UTF-8" Hi Dave, On Wed, Jan 2, 2019 at 6:44 PM Dave Page wrote: > Packagers, > > As you probably know, pgAdmin 4 checks for updates upon startup, and > if a newer version is available, directs the user to www.pgadmin.org > to download it. > > The is a problem if your pgAdmin came with a PostgreSQL installer (as > you can't download them from our website), and potentially mildly > annoying if you're a .deb or .rpm user. > > There are a couple of ways to optimise the experience for users here > (one of which I just committed). I'll leave it up to each of you to > choose what you want to do (Sandeep, I would suggest that the EDB > installers use method 2). > > Method 1: Simply disable the upgrade check, and leave that to the > operating systems update tools. To do this, create (or edit) a > config_distro.py file that is installed alongside the config.py file > from the pgAdmin source and include the line; > > UPGRADE_CHECK_ENABLED = False > > Method 2: For well known and trusted distributions we can support a > custom check for your distribution. This involves 2 parts: > > 1) Let me know that you want a custom check, and I'll setup access for > you to manage the version data on the pgAdmin website. We'll agree on > a custom key for that data within the JSON file the website hosts. > > We want that for PG and EPAS installers. Will you please share the custom key? > 2) Create (or edit) a config_distro.py file that is installed > alongside the config.py file from the pgAdmin source and include the > line; > > UPGRADE_CHECK_KEY = '' > > With this method, a different section of the JSON datafile will be > checked by your distribution of pgAdmin, thus allowing you to control > both when it tells users a new version is available, and the URL to > which they are directed. > > Makes sense. Will include this change in the upcoming PG and EPAS updates that bundle pgAdmin. > Thanks! > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > -- Sandeep Thakkar --000000000000f93bc0058124baac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave,


On Wed, Jan 2, 2019= at 6:44 PM Dave Page <dpage@pgadmi= n.org> wrote:
Packagers,

As you probably know, pgAdmin 4 checks for updates upon startup, and
if a newer version is available, directs the user to www.pgadmin.org
to download it.

The is a problem if your pgAdmin came with a PostgreSQL installer (as
you can't download them from our website), and potentially mildly
annoying if you're a .deb or .rpm user.

There are a couple of ways to optimise the experience for users here
(one of which I just committed). I'll leave it up to each of you to
choose what you want to do (Sandeep, I would suggest that the EDB
installers use method 2).

Method 1: Simply disable the upgrade check, and leave that to the
operating systems update tools. To do this, create (or edit) a
config_distro.py file that is installed alongside the config.py file
from the pgAdmin source and include the line;

UPGRADE_CHECK_ENABLED =3D False

Method 2: For well known and trusted distributions we can support a
custom check for your distribution. This involves 2 parts:

1) Let me know that you want a custom check, and I'll setup access for<= br> you to manage the version data on the pgAdmin website. We'll agree on a custom key for that data within the JSON file the website hosts.

We want that for PG and EPAS installers. Will you ple= ase share the custom key?
=C2=A0
2) Create (or edit) a config_distro.py file that is installed
alongside the config.py file from the pgAdmin source and include the
line;

UPGRADE_CHECK_KEY =3D '<your key>'

With this method, a different section of the JSON datafile will be
checked by your distribution of pgAdmin, thus allowing you to control
both when it tells users a new version is available, and the URL to
which they are directed.

Makes sense. Will include this change in the upcoming= PG and EPAS updates that bundle pgAdmin.
=C2=A0
Thanks!

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


--
Sandeep Thakkar

--000000000000f93bc0058124baac--