Consider aligning Phoenix releases with Firefox trains #325

degausser commented 2026年06月23日 22:07:46 +02:00

Please explain your inquiry.

https://whattrainisitnow.com/

phoenix 2026年06月10日.1 came out a week before 152, missing on some nice-to-have fixes vs. dev. intentionally setting the release cadence to let's say up to around .1 point release - i think mozilla committed to ~4 point releases per version for now - would hopefully give enough time to look at new changes and still ensure new fixes landing asap (i see march, april & may releases try to adhere to this). adjusting the versioning scheme to match upstream might be also worth thinking about - the config is not really a date snapshot of a still document; it often meaningfully changes specifically with a new firefox version. basically any phoenix release without new firefox fixes (so not in the ~last third of the month), is essentially a hotfix/point release for the previous firefox version.

### Please explain your inquiry. https://whattrainisitnow.com/ phoenix `2026年06月10日.1` came out a week before 152, missing on some nice-to-have fixes vs. `dev`. intentionally setting the release cadence to let's say up to around `.1` point release - _i think_ mozilla committed to ~4 point releases per version for now - would hopefully give enough time to look at new changes and still ensure new fixes landing asap _(i see march, april & may releases try to adhere to this)_. adjusting the versioning scheme to match upstream might be also worth thinking about - the config is not really a date snapshot of a still document; it often meaningfully changes specifically with a new firefox version. basically any phoenix release without new firefox fixes (so not in the ~last third of the month), is essentially a hotfix/point release for the previous firefox version.

celenity commented 2026年06月23日 23:46:25 +02:00

Thanks for filing this!

I'm inclined to agree with you here (would be especially nice for browsers integrating Phoenix, so they can update Phoenix to coincide with a new FF release). I think the only concern is giving people (and package maintainers) enough time to update Firefox (So, for example, if we remove a pref that no longer applies to a new release or ESR, and someone updates Phoenix before updating to the new Firefox release, I wouldn't want them missing out on that pref).

I do think this is definitely worth pursuing though, and in general I think it'd be very beneficial to have a consistent release schedule as well.

For one possible solution, we could maybe make a new Phoenix release ~a day or 2 before a new Firefox release, then just wait ~2-3 days after the Firefox version releases to update Phoenix's packaging.

@degausser Curious to hear your thoughts/if you have any ideas or suggestions on the best way to handle this.

Thanks for filing this! I'm inclined to agree with you here *(would be especially nice for browsers integrating Phoenix, so they can update Phoenix to coincide with a new FF release)*. I think the only concern is giving people *(and package maintainers)* enough time to update Firefox *(So, for example, if we remove a pref that no longer applies to a new release or ESR, and someone updates Phoenix before updating to the new Firefox release, I wouldn't want them missing out on that pref)*. I do think this is definitely worth pursuing though, and in general I think it'd be very beneficial to have a consistent release schedule as well. For one possible solution, we could maybe make a new Phoenix release ~a day or 2 before a new Firefox release, then just wait ~2-3 days after the Firefox version releases to update Phoenix's packaging. @degausser Curious to hear your thoughts/if you have any ideas or suggestions on the best way to handle this.

degausser commented 2026年06月24日 01:49:43 +02:00

@celenity

it'd be very beneficial to have a consistent release schedule

couldn't agree more

giving people (and package maintainers) enough time

well, however it may seem, package maintainers are people too :)

first firefox point release is generally at least a week after .0; most distros/users would have at least .0 by that point. adjusted versioning scheme would also provide a hint (phoenix x.y corresponds to firefox x.y). not much of a datapoint, but fwiw the trains website has a % adoption/rollout note next to versions (presumably based on telemetry), 152.0.1 after a ~week sits at 60% adoption.

imho it is better to cut a new phoenix release a ~week (or however long the research takes) after corresponding firefox .0 with new version relevant fixes, than 2-3 days before without. delayed packaging doesn't really matter; some changes are unfortunately only really noticeable at runtime. i don't know if you testrun beta/rc versions of firefox before release, i assume you do not; post-release phoenix would also benefit from user feedback about unwanted changes (on old config), which could then immediately be incorporated.

for browsers integrating Phoenix, so they can update Phoenix to coincide with a new FF release

they would have to wait for phoenix, or cherrypick from the dev branch - like they would now

---

re: packaging, how is phoenix going to be handled in "stable" debian-based distros (e.g. various ubuntus, debian forky)? i see @gnu1 tries to keep up with phoenix updates as best as they can (in sid), but if the distro-packaged version is frozen along with other packages and only grows more obsolete since then (see yt-dlp in trixie as an example, or phoenix already in ubuntu), i think it may be worth to discourage people from relying on distro-packaged phoenix on debian & derivatives for firefox stable (!=esr) - see support table in readme. ubuntu doesn't even package firefox-esr, so current lts being stuck on phoenix 2026年02月16日.1 forever is... very unfortunate. even with firefox-esr after debian forky gets released, it will inevitably roll over to esr-next during the distro's lifespan, if phoenix is not at least then updated in backports to match, users will be missing important changes.

@celenity >it'd be very beneficial to have a consistent release schedule couldn't agree more >giving people (and package maintainers) enough time well, however it may seem, package maintainers are people too :) first firefox point release is generally at least a week after `.0`; most distros/users would have at least `.0` by that point. adjusted versioning scheme would also provide a hint (phoenix x.y corresponds to firefox x.y). not much of a datapoint, but fwiw the trains website has a % adoption/rollout note next to versions (presumably based on telemetry), `152.0.1` after a ~week sits at [60% adoption](https://whattrainisitnow.com/release/?version=release#:~:text=152%2E0%2E1). **imho it is better to cut a new phoenix release a ~week (or however long the research takes) after corresponding firefox `.0` _with new version relevant fixes,_ than 2-3 days before _without_.** delayed packaging doesn't really matter; some changes are unfortunately only really noticeable at runtime. i don't know if you testrun beta/rc versions of firefox before release, i assume you do not; post-release phoenix would also benefit from user feedback about unwanted changes (on old config), which could then immediately be incorporated. >for browsers integrating Phoenix, so they can update Phoenix to coincide with a new FF release they would have to wait for phoenix, or cherrypick from the dev branch - like they would now ___ _re: packaging_, how is phoenix going to be handled in "stable" debian-based distros (e.g. various ubuntus, debian forky)? i see @gnu1 tries to keep up with phoenix updates as best as they can (in sid), but if the distro-packaged version is frozen along with other packages and only grows more obsolete since then (see [yt-dlp](https://packages.debian.org/search?keywords=yt-dlp) in trixie as an example, or phoenix already in [ubuntu](https://packages.ubuntu.com/search?keywords=phoenix)), i think it may be worth to discourage people from relying on distro-packaged phoenix on debian & derivatives for _firefox stable_ (!=esr) - see support table in readme. ubuntu doesn't even package firefox-esr, so current lts being stuck on phoenix `2026年02月16日.1` forever is... _very unfortunate_. even with firefox-esr after debian forky gets released, it will inevitably roll over to esr-next during the distro's lifespan, if phoenix is not at least then updated in backports to match, users will be missing important changes.

Gnu1 commented 2026年06月24日 06:02:57 +02:00

Hi,

how is phoenix going to be handled in "stable" debian-based distros

By supporting Firefox-ESR!

i see @gnu1 tries to keep up with phoenix updates as best as they can (in sid), but if the distro-packaged version is frozen along with other packages and only grows more obsolete since then (see yt-dlp in trixie as an example, or phoenix already in ubuntu),

It is simple, it you want to be up to date use Debian testing. it is both stable and up to date.

i think it may be worth to discourage people from relying on distro-packaged phoenix on debian & derivatives for firefox stable (!=esr) - see support table in readme. ubuntu doesn't even package firefox-esr, so current lts being stuck on phoenix 2026年02月16日.1 forever is... very unfortunate.

I want to keep phoenix up-to-date, but there are two issues. it has too many updates and in each update its file tree will be changed a lot! they make updating phoenix difficult. And unfortunately the upstream debian packaging is very non-standard!
So I strongly dislike relying on the informal repository. Of course Celenity decide for it.

Hi, >how is phoenix going to be handled in "stable" debian-based distros By supporting Firefox-ESR! > i see @gnu1 tries to keep up with phoenix updates as best as they can (in sid), but if the distro-packaged version is frozen along with other packages and only grows more obsolete since then (see yt-dlp in trixie as an example, or phoenix already in ubuntu), It is simple, it you want to be up to date use Debian testing. it is both stable and up to date. >i think it may be worth to discourage people from relying on distro-packaged phoenix on debian & derivatives for firefox stable (!=esr) - see support table in readme. ubuntu doesn't even package firefox-esr, so current lts being stuck on phoenix 2026年02月16日.1 forever is... very unfortunate. I want to keep phoenix up-to-date, but there are two issues. it has too many updates and in each update its file tree will be changed a lot! they make updating phoenix difficult. And unfortunately the upstream debian packaging is very non-standard! So I strongly dislike relying on the informal repository. Of course Celenity decide for it.

degausser commented 2026年06月24日 10:18:30 +02:00

@gnu1

By supporting Firefox-ESR!

again, ubuntu doesn't package firefox esr at all, but does package an obsolete phoenix version. this version will be inadequate for esr-next anyways (153esr will replace 140esr sometime in september). the support table in phoenix readme has a green tickbox for firefox stable for both debian and ubuntu...

if you want to be up to date

it's not a matter of "wanting" anything, using an inappropriate config can be potentially harmful to users on firefox-release, and esr-next

use Debian testing

testing gets general security fixes last, after both stable(-security) and sid. surely you're not telling me to make a frankendebian...

imo, phoenix should be included in forky-backports (after forky becomes stable), and dilligently kept up to date there. ubuntu / anything downstream is still a problem though, fixable only by relying on the "informal" repo (obs / ppa of sorts), or manual install.

@gnu1 >By supporting Firefox-ESR! again, ubuntu doesn't package firefox esr at all, but does package [an obsolete phoenix version](https://packages.ubuntu.com/resolute/phoenix). this version will be inadequate for esr-next anyways (153esr will replace 140esr sometime in september). the support table in phoenix readme has a green tickbox for firefox stable for both debian and ubuntu... >if you want to be up to date it's not a matter of "wanting" anything, using an inappropriate config can be potentially harmful to users _on firefox-release, and esr-next_ >use Debian testing testing [gets general security fixes last](https://www.debian.org/doc/manuals/securing-debian-manual/ch10.en.html#security-support-testing), after both stable(-security) and sid. surely you're not telling me to make a [frankendebian](https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian)... imo, phoenix should be included in forky-backports (after forky becomes stable), and dilligently kept up to date there. ubuntu / anything downstream is still a problem though, fixable only by relying on the "informal" repo (obs / ppa of sorts), or manual install.

Gnu1 commented 2026年06月24日 11:17:39 +02:00

again, ubuntu doesn't package firefox esr at all, but does package an obsolete phoenix version. this version will be inadequate for esr-next anyways (153esr will replace 140esr sometime in september). the support table in phoenix readme has a green tickbox for firefox stable for both debian and ubuntu...

The DEB package supports both (DEB) FireFox and FireFox-ESR.
It is entirely possible that such big third-party changes to Firefox settings could cause problems.

testing gets general security fixes last, after both stable(-security) and sid. surely you're not telling me to make a frankendebian...

Because Debian testing & sid are up-to-date, they almost do not need a security repository.

What exactly do you want from me?

>again, ubuntu doesn't package firefox esr at all, but does package an obsolete phoenix version. this version will be inadequate for esr-next anyways (153esr will replace 140esr sometime in september). the support table in phoenix readme has a green tickbox for firefox stable for both debian and ubuntu... The DEB package supports both (DEB) FireFox and FireFox-ESR. It is entirely possible that such big third-party changes to Firefox settings could cause problems. >testing gets general security fixes last, after both stable(-security) and sid. surely you're not telling me to make a frankendebian... Because Debian testing & sid are up-to-date, they almost do not need a security repository. What exactly do you want from me?

degausser commented 2026年07月10日 20:30:24 +02:00

@celenity

https://groups.google.com/a/mozilla.org/g/dev-platform/c/qlaQ1YSlOP8
https://whattrainisitnow.com/calendar/

@celenity https://groups.google.com/a/mozilla.org/g/dev-platform/c/qlaQ1YSlOP8 https://whattrainisitnow.com/calendar/