Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tH1J0-002afV-OC for pgadmin-hackers@arkaria.postgresql.org; Fri, 29 Nov 2024 13:45:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tH1Iy-007vH8-1k for pgadmin-hackers@arkaria.postgresql.org; Fri, 29 Nov 2024 13:45:09 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tH1Ix-007vH0-ID for pgadmin-hackers@lists.postgresql.org; Fri, 29 Nov 2024 13:45:09 +0000 Received: from mail-lj1-x22f.google.com ([2a00:1450:4864:20::22f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tH1Iv-000Agk-9d for pgadmin-hackers@postgresql.org; Fri, 29 Nov 2024 13:45:07 +0000 Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2ffe2700e91so15444621fa.2 for ; Fri, 29 Nov 2024 05:45:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1732887903; x=1733492703; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vltZ88dzK4au9j5B1xuMa2ikR7R0RZ2vCMLyribJzIg=; b=ozq8mpyqxFiQI7WQq0bi1GlCUAFG12VrRtaqtK+OWbjA8HIJGO7DBJT+8FbhaTGIsO 0AM+td5dh9B+R7U8exBoO3XhzELFJ/9v1mRiZhWybx3Zc0IBA4J3wR1kK+zZAUzYfhhV bFhhT14Qik70tb4+iC+2PFJLsxX3hLpOPdtAkgGccFllJxTD+L8gjucPtw/XESXyv0zn WFV1fHiQoznaM1XnsnC8571GrZhv3aD5kuD5PRQ5eV9sNGqA/H7S+Um+l2odvOBX71IS BqXSBbeDJPlQZ+QU2yUiv9Ixlh8Gh34qWuwET25YVS3bUh4Lm0elzEJWLkt8IBmen8RY mFBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732887903; x=1733492703; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vltZ88dzK4au9j5B1xuMa2ikR7R0RZ2vCMLyribJzIg=; b=xH23CjnbZxz+F8Xx5mxpNFK933erBR1Kz99lBn5vrmw8kKlsshp76gYMEGKP6YGqor QBN7S4E8aGXqY3xA04jIEcUmMEeRi2j+2HmoFhdFR/3+n+IWPuSXjr/2Ru2/dOViFZwg m1sFmA+XjcLA5+d31PCvsUbqM3/I0/NM1vX7QBfhGb6RJjS5U/4ujKK+66aR4bCQ/7WO vh2DknadQOxv8kfLwnJ35Jzsm2Xd0Kv9J0n0i0o5cCuv5gz57oZBNw6BXQsmjxlOmg0O JLAdt4zeLuN3cX8s7KcSS7i3sqw4cn8/y8MNy+xMvYKkBivjEMp9bjzfEJMQPQ++r2B3 o9JQ== X-Gm-Message-State: AOJu0YxgfDiKqOB4je1ZRGzZ8YJaRHLWEMRbe0/sVUAZhLJOpyCCx5Od 6l/+hGlYJP0yB0NaIFd34PhyyzSfYOR9wmmW0dt8iDE9U+KaleqmwaJZxByJvGiN9IzNstY+mwb tcpPaWHl7Cefb6IpyqqC7dWi38CJfVvzvUaBPnytHkjjRUD47gQ== X-Gm-Gg: ASbGncvqA2jCO3/HHKHQswFrAHK6p3PbbLxq5rUQz/wKzl3jxtJuPGIW+SKLRn5Tl4J CClfrWp1hprdPRNPGeD9fmFOss2d7nXxB X-Google-Smtp-Source: AGHT+IGgsu7HqMKKmrQk5vVSOkXsN0K/CpRwBX36r4j1cRjACw0YHgQDl2axTyGASny+ip4TgcfhkhauKpuo2i5Pg8Q= X-Received: by 2002:a2e:be24:0:b0:2ff:cef6:3189 with SMTP id 38308e7fff4ca-2ffd5fcc620mr73919021fa.1.1732887903050; Fri, 29 Nov 2024 05:45:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Fri, 29 Nov 2024 13:44:51 +0000 Message-ID: Subject: Re: Require suggestions on feature #5766 To: Anil Sahoo Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000e5b71606280d6786" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e5b71606280d6786 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi On Thu, 28 Nov 2024 at 11:38, Anil Sahoo wrote: > Hi Dave, > > I have mentioned the requirements for the deployment server to add > auto-update in macOs systems. > > > The frontend will request deployment server with Accept: application/json > and the current version of pgAdmin and the architecture of macOs system a= nd > server will check if any update is available or not, if update available > then server responds with status code 200 OK and sends the below format > JSON response in the body. > > > Example of deployment url: > https://your-deployment-url.com/update/darwin/8.12 > > > Example of response: > > { > "url": "https://your-deployment-url.com/your-app-8.13-darwin.zip", > "name": "8.13", > "notes": "Theses are some release notes innit", > "pub_date": "2024-09-18T12:29:53+01:00" > } > > > Here url is mandatory and others are optional. > > Squirrel will request "url" with Accept: application/zip and only support= s > installing ZIP updates. > > "pub_date" if present must be formatted according to ISO 8601. > > > If no update is required, the server must respond with a status code > of 204 No Content. > Ah, OK - so it's just the metadata. We can handle that pretty easily in the pgaweb code. > > > And for Windows systems, Electron recommended to use electron-winstaller > or electron forge as using these packages will use Squirrel.Windows for > creating windows installer and that will help in triggering custom launch > events and that can be handled by our application for proper setup. But > what I think is, as we are using Inno setup for creating our Windows > installer, we can try updating our application with existing way only, if > something does not work then we have the option to change our installer > creation process. > So one thing that springs to mind is that on Windows, this is only likely to work with per-user installations, however, generally the default is for machine-wide installations. Have you given that any thought? > > Thanks, > > Anil > > On Wed, Nov 27, 2024 at 10:34=E2=80=AFPM Dave Page wr= ote: > >> Hi! >> >> On Wed, 27 Nov 2024 at 07:58, Anil Sahoo >> wrote: >> >>> Hi Dave/Team, >>> >>> I am currently working on the auto-update feature of pgAdmin 4 desktop >>> application, #5766 >>> . >>> >>> >>> As we are using Electron for shipping our desktop application, I have >>> gone through some possible ways we can implement the auto update of the >>> app. >>> >>> I found 2 most popular ways, that are >>> >>> 1. *Use builtin electron=E2=80=99s autoUpdater* (Uses the Squirrel f= ramework >>> & Available for Mac, Windows) >>> 2. *Use electron-builder and electron-updater packages *(Available >>> for Mac, Windows and Linux systems) >>> >>> *Linux systems:* >>> >>> >>> - Builtin Electron=E2=80=99s autoUpdater support is not available. >>> - electron-builder and electron-updater can be used, but need to >>> change the whole build process. Also most apps like VS code, Chrome,= etc >>> does not support auto-update of apps on linux systems. >>> >>> We should not try to auto-update on Linux, because we're using the >> platform native packaging and auto-updating will cause nasty problems wi= th >> that. >> >> >>> *Mac systems:* >>> >>> - We can use the builtin Electron=E2=80=99s autoUpdater to add auto-= update >>> feature to macOs systems, It is simple and easy to configure. We nee= d a >>> minor modification in our build process i.e. as we are supporting In= tel and >>> Apple silicon chips, deployment url will have 2 zip files and each z= ip file >>> will hold the build for arm64 and x86_64. >>> - electron-builder and electron-updater can be used. With this, we >>> have to change the whole build process. >>> >>> *Windows systems:* >>> >>> - We can use the builtin Electron=E2=80=99s autoUpdater to add auto-= update >>> feature to windows systems, Here also we need to change our build pr= ocess. >>> Electron=E2=80=99s docs recommend using electron-winstaller or elect= ron forge to >>> create the installer and some extra changes are needed in the deploy= ment >>> server. >>> - electron-builder and electron-updater can be used. With this, we >>> have to change the whole build process. >>> >>> As Electron's builtin autoUpdater is easy to use so for now we can move >>> with the auto-update of the pgAdmin app on macOs systems as it requires >>> minimal changes. >>> >> >> That certainly sounds like the better option. A couple of questions: >> >> - What changes are required in the deployment server? We are very limite= d >> here, as we deploy through the postgresql.org infrastructure. >> >> - Whilst the docs (for Windows) recommend using electron-winstaller or >> electron forge, can you confirm one of them *must* be used? Our current >> installer is pretty standard in the way it works, so I'm curious to know= if >> we would actually need to change technology for a specific reason. >> >> Thanks! >> >> -- >> Dave Page >> pgAdmin: https://www.pgadmin.org >> PostgreSQL: https://www.postgresql.org >> pgEdge: https://www.pgedge.com >> >> > > -- > > > *Anil Sahoo* > > Software Development Engineer II > > LinkedIn || Blog > || *GitHub > * > > enterprisedb.com > --=20 Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com --000000000000e5b71606280d6786 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Thu, 28 Nov 2024 at 11:38,= Anil Sahoo <anil.sahoo@e= nterprisedb.com> wrote:
H= i Dave,

I have mentioned the req= uirements for the deployment server to add auto-update in macOs systems.


The frontend will reques= t deployment server with Accept: application/json and the current version o= f pgAdmin and the architecture=C2=A0of macOs system and server will check i= f any update is available or not, if update available then server responds = with status code 200 OK=C2=A0 and sends the below format JSON = response in the body.


Example of depl= oyment url: https://your-deployment-url.com/update/darwin/8.12


=

Example = of response:

{
=C2=A0 =C2=A0 "= ;url": "https://your-deployment-url.com/your-app-8.13= -darwin.zip",
=C2=A0 =C2=A0 "name": "8.13",=
=C2=A0 =C2=A0 "notes": "Theses are some release notes in= nit",
=C2=A0 =C2=A0 "pub_date": "2024-09-18T12:29:53= +01:00"
}


Here url is mandatory an= d others are optional.

Squirrel will request &q= uot;url" with=C2=A0Accept: application/zip=C2=A0and only supports inst= alling ZIP updates.

"pub_date" if = present must be formatted according to ISO 8601.


If no update is required= , the server must respond with a status code of=C2=A0204 No Content.


Ah, OK - so it's just the met= adata. We can handle that pretty easily in the pgaweb code.
=C2= =A0



And for Windows systems,= Electron recommended to use electron-winstaller or electron forge as using= these packages will use Squirrel.Windows for creating windows installer an= d that will help in triggering custom launch events and that can be handled= by our application for proper setup. But what I think is, as we are using = Inno setup for creating our Windows installer, we can try updating our appl= ication with existing way only, if something does not work then we have the= option to change our installer creation process.


So one thing that springs to mind is that on Windows= , this is only likely to work with per-user installations, however, general= ly the default is for machine-wide installations. Have you given that any t= hought?
=C2=A0


Thanks,

Anil


On Wed, Nov 27, 2024 at 10:34=E2=80=AFPM Dave= Page <dpage@pgad= min.org> wrote:
Hi!<= /div>
O= n Wed, 27 Nov 2024 at 07:58, Anil Sahoo <anil.sahoo@enterprisedb.com> wrote= :

Hi Dave/Team,

I am currently working on the auto-up= date feature of pgAdmin 4 desktop application, #5766.


As we are using Electron= for shipping our desktop application, I have gone through some possible wa= ys we can implement the auto update of the app.

I found 2 most popular ways, that are

  1. Use builtin electron= =E2=80=99s autoUpdater (Uses the Squirrel framework & Available for= Mac, Windows)
  2. Use electron-builder= and electron-updater packages=C2=A0(Available for Mac, Windows and Lin= ux systems)

Linux systems:

  • Builtin Elec= tron=E2=80=99s autoUpdater support is not available.
  • electron-build= er and electron-updater can be used, but need to change the whole build pro= cess. Also most apps like VS code, Chrome, etc does not support auto-update= of apps on linux systems.=C2=A0
We should not try to auto-update on Linux, because we'r= e using the platform native packaging and auto-updating will cause nasty pr= oblems with that.
=C2=A0
<= div dir=3D"ltr">

Mac systems:

<= ul>
  • We can use the builtin Electron=E2=80=99s autoUpdater to add auto-update= feature to macOs systems, It is simple and easy to configure. We need a mi= nor modification in our build process i.e. as we are supporting Intel and A= pple silicon chips, deployment url will have 2 zip files and each zip file = will hold the build for arm64 and x86_64.
  • electron-builder a= nd electron-updater can be used. With this, we have to change the whole bui= ld process.=C2=A0

    • Windows systems:<= /p>

    • We can use the builtin Electron=E2=80=99s autoUpdater to add auto-up= date feature to windows systems, Here also we need to change our build proc= ess. Electron=E2=80=99s docs recommend using electron-winstaller or electro= n forge to create the installer and some extra changes are needed in the de= ployment server.
    • electron-builder and electron-updater can b= e used. With this, we have to change the whole build process.=C2=A0

    As Electron's builti= n autoUpdater is easy to use so for now we can move with the auto-update of= the pgAdmin app on macOs systems as it requires minimal changes.

    =

    That certainly sounds like the= better option. A couple of questions:

    - What chan= ges are required in the deployment server? We are very limited here, as we = deploy through the post= gresql.org infrastructure.

    - Whilst the docs (= for Windows) recommend using electron-winstaller or electron forge, can you= confirm one of them *must* be used? Our current installer is pretty standa= rd in the way it works, so I'm curious to know if we would actually nee= d to change technology for a specific reason.

    Than= ks!
    =C2=A0
    -- <= /span>


    --


    Anil Sahoo=

    Software Develop= ment Engineer II

    LinkedIn=C2=A0|| Blog= =C2=A0|| GitHub


    enterprisedb.com

    <= /span>


    --
    --000000000000e5b71606280d6786--