Subject: Support for listing the beta versions

From: Jonathan Abdiel Gonzalez Valdebenito <[email-masked]>
Date: Mon, 18 Aug 2025 14:18:40 +0200

Hello,

Sometime ago I find out about this beautiful URL
https://www.postgresql.org/versions.json which turns out to be really
useful to get the latest available versions of PostgreSQL for automation
process(building and testing mostly) but I sadly find out that the beta
versions aren't listed.

To show first how we use it first we parse and transform the content[1]
into a compatible format that is useful for us (HCL), this is then
updated[2] to make the build process easy and transparent for testing[3] in
other projects.

Does the site provide a way to get the active beta versions or is there a
plan to publish those active beta versions?

I know that most people will ask themself "why is this useful?" but testing
beta versions is really useful to detect bugs and also, having that
automated it's something really useful so people can focus on the bugs not
on remembering to update some configuration file.

Regards!

[1]
https://github.com/cloudnative-pg/postgres-containers/pull/269/files#diff-ff9c56df6264f225b05fd0745304138d7da5a9ac2131474d13a13d99adbe2c09R29
[2]
https://github.com/cloudnative-pg/postgres-containers/blob/main/docker-bake.hcl#L35
[3] https://github.com/cloudnative-pg/postgres-trunk-containers/

---

From: Jonathan Abdiel Gonzalez Valdebenito <[email-masked]>
Date: Mon, 18 Aug 2025 15:16:00 +0200

Hello,

To complement my previous email, since people may be using the file in
different ways, and probably will affect to add a new version
I propose to add an argument "beta=true" to the URL, which by default will
be false, keeping the same behavior, but if is added, will also
list the beta versions on the json file, allowing backward compatibility
and an easy way to include the beta versions without adding a
new file or entry in the json file.

Regards!

---

From: Magnus Hagander <[email-masked]>
Date: Mon, 1 Dec 2025 21:30:00 +0100

> new file or entry in the json file.

Hi!

Sorry for a very late feedback on this.

I think this is the way it has to be done, more or less. I was trying to
think of a better way back when you sent it, and then didn't but forgot to
reply :)

Now, beta isn't enough. We technically have alpha, beta and rc. Should we
make it something like "?include=beta,rc" and a chance to list them? Or
should we have "testing=beta" and have it basically do "if you say alpha
you get all, if you say beta you get beta and rc and if you say rc you get
rc"? Which would make more sense?

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ <http://www.hagander.net/>
 Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

---

From: "Jonathan Gonzalez V." <[email-masked]>
Date: Thu, 04 Dec 2025 10:35:42 +0100

Hello!

> Sorry for a very late feedback on this.
Thank you for taking the time! :D 

> Now, beta isn't enough. We technically have alpha, beta and rc.
> Should we make it something like "?include=beta,rc" and a chance to
> list them? Or should we have "testing=beta" and have it basically do
> "if you say alpha you get all, if you say beta you get beta and rc
> and if you say rc you get rc"? Which would make more sense?

Well, I was being a bit conservative since I didn't know if people
would like the idea, but yes, indeed! if we can have the beta alpha and
rc versions too, that will be amazing! Specially because that will
allow people to start testing early versions in their automated system.

My python it's a bit rusty but I can help testing if you need!

Regards,

-- 
Jonathan Gonzalez V. <[email-masked]>

---

From: Yogesh Sharma <[email-masked]>
Date: Wed, 27 May 2026 10:04:52 -0400

On 12/1/25 15:30, Magnus Hagander wrote:
> 
> 
> On Mon, 18 Aug 2025 at 15:16, Jonathan Abdiel Gonzalez Valdebenito 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hello,
> 
>     To complement my previous email, since people may be using the file
>     in different ways, and probably will affect to add a new version
>     I propose to add an argument "beta=true" to the URL, which by
>     default will be false, keeping the same behavior, but if is added,
>     will also
>     list the beta versions on the json file, allowing backward
>     compatibility and an easy way to include the beta versions without
>     adding a
> think of a better way back when you sent it, and then didn't but forgot 
> to reply :)
> 
> Now, beta isn't enough. We technically have alpha, beta and rc. Should 
> we make it something like "?include=beta,rc" and a chance to list them? 
> Or should we have "testing=beta" and have it basically do "if you say 
> alpha you get all, if you say beta you get beta and rc and if you say rc 
> you get rc"? Which would make more sense?
> 

Another idea:

   {
     "current": false,
     "eolDate": "2031-11-08",
     "firstRelDate": "2026-10-14",
     "latestMinor": "beta1",
     "major": "19",
     "relDate": "2026-05-14",
     "supported": true
     "upcoming" : true
   },

I am in favor of adding alpha/beta/rc/ in json in some form.

Thanks
Yogesh