Bugzilla

I created this api locally:

```json
{
   "nightly":{
      "version":153,
      "release_date":"2026-07-21"
   },
   "beta":{
      "version":152,
      "release_date":"2026-06-16",
      "has_betas_left":true,
      "is_rc_shipped":false
   },
   "release":{
      "version":151,
      "release_date":"2026-05-19"
   }
}
```
I think the extra fields in the beta section should be enough to create your widget.

The `has_betas_left` boolean will tell you if we have shipped all of our betas. 
The `is_rc_shipped` boolean will tell you if we have shipped our Release Candidate 

`has_betas_left = true` => uplift targets the beta branch
`has_betas_left = false` => uplift targets the release branch
`has_betas_left = false` + `is_rc_shipped = false` => uplift targets the release branch and should be in the major 152.0 release 
`has_betas_left = false` + `is_rc_shipped = true` => uplift targets the release branch and should be a 152.0.x minor release 

If the uplift is for a patch on main (nightly 153 here) and the target requested is release 151, then we should propose to uplift to both beta and release branches.

Would that work for you Connor? I can put that endpoint on production if you want to play with it.

Note that at the end of the cycle, for the last beta and the rc there will be a few hours gap where this will be slightly off, that is when we are building the last beta and the last RC but haven't shipped it yet. At this point the api would not reflect the fact that uplifts are no longer open for last beta or rc as we are building it. I think it should be OK in practice but we could shorten this window of uncertainty for at least beta if we see that we have confusion.

I created this api locally:

```json
{
   "nightly":{
      "version":153,
      "release_date":"2026-07-21"
   },
   "beta":{
      "version":152,
      "release_date":"2026-06-16",
      "has_betas_left":true,
      "is_rc_shipped":false
   },
   "release":{
      "version":151,
      "release_date":"2026-05-19"
   }
}
```
I think the extra fields in the beta section should be enough to create your widget.

The `has_betas_left` boolean will tell you if we have shipped all of our betas. 
The `is_rc_shipped` boolean will tell you if we have shipped our Release Candidate 

`has_betas_left = true` => uplift targets the beta branch
`has_betas_left = false` => uplift targets the release branch
`has_betas_left = false` + `is_rc_shipped = false` => uplift targets the release branch and should be in the major 152.0 release 
`has_betas_left = false` + `is_rc_shipped = true` => uplift targets the release branch and should be in a 152.0.x minor release 

If the uplift is for a patch on main (nightly 153 here) and the target requested is release 151, then we should propose to uplift to both beta and release branches.

Would that work for you Connor? I can put that endpoint on production if you want to play with it.

Note that at the end of the cycle, for the last beta and the rc there will be a few hours gap where this will be slightly off, that is when we are building the last beta and the last RC but haven't shipped it yet. At this point the api would not reflect the fact that uplifts are no longer open for last beta or rc as we are building it. I think it should be OK in practice but we could shorten this window of uncertainty for at least beta if we see that we have confusion.