On 12/1/25 15:30, Magnus Hagander wrote:
>
>
> On Mon, 18 Aug 2025 at 15:16, Jonathan Abdiel Gonzalez Valdebenito
> <jonathan.abdiel@gmail.com <mailto:jonathan.abdiel@gmail.com>> 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
> new file or entry in the json file.
>
> Regards!
>
>
> 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?
>
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
