Firefox pkg for 6.6-stable will not receive latest updates. [Updated]

Adding more details, since i feel the need to clear some things, and some users might get alarmed by the title...it makes it sound like www/mozilla-firefox in 6.6-stable received updates in the past, which isnt the case - 6.6-stable is in the state it was when 6.6 was released, ie shipping 69.0. In 6.6-stable, www/firefox-esr *is* updated to the latest version of the esr branch, because it's 'easy' to do.

As a reminder, -stable has always been on a case by case basis, and best effort, depending on developer time (and interest). That said, some past releases received updates for www/mozilla-firefox, when it was easy to do them. For example, 6.4-stable received updates up to 63.0.3, but didnt receive 64.0 and newer versions because it required a newer cbindgen version. In 6.3-stable, www/mozilla-firefox got updated from 59 to 60, then tracked the 60esr branch, because updating to newer versions was complicated. I could go on, but looking at cvs history and commit messages for tags & branches on http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/mozilla-firefox/distinfo will give you an idea.

What is complicated ? Well:
- newer firefox releases tend to *require* newer versions of rust and cbindgen (see history of the requirements on https://hg.mozilla.org/mozilla-central/log/tip/build/moz.configure/bindgen.configure and https://hg.mozilla.org/releases/mozilla-release/log/tip/build/moz.configure/rust.configure), which are external codebases and we tend to avoid backporting newer versions of things that might have side-effects (ie we *might* be able to update cbindgen, as its only used by firefox, but updating rust in -stable means testing all its consumers). Sometimes, this requirement is just a configure time check that we can patch out, sometimes the codebase really requires those newer versions or you need to backout huge chunks of code. No fun.
- newer firefox releases *require* newer sqlite/nspr/nss versions. Same thing, sometimes its only a configure time check, sometimes its a real requirement - in that case, we can resort to build against the bundled version of those libs (which is always the required version), which means making sure that doesnt have side effects, and reapplying some of our patches (some nss & nspr patches are feature patches which arent upstreamed). No fun.
- it always depends on the situation of the upstream codebase, and the OpenBSD release cycle. Sometimes its easy, sometimes its not. And if you start backing out patches, you are in a configuration which is even less supported upstream. No fun.
- it takes developer time, and cpu time. And runtime testing. No fun.

But rejoice ! It seems solene@ decided to try nevertheless (cf https://marc.info/?t=157885848500002&r=1&w=2), as 72.0 requires rust 1.37 and cbindgen 0.9.1 it might actually work. Who knows ? Well, if you run -stable and you care, *you should try and give feedback*. I wish her good luck in this endeavour. (Been there, done that, no fun.) Note that this doesnt say it will be possible for 73.0 ;)

As for the esr branches, there's no easy solution either. The upstream calendar at https://wiki.mozilla.org/Release_Management/Calendar makes it clear for which amount of time an esr release is supported. For 68.0esr for example, supports ends in august, but the next esr (78.0esr) wont be released by then - so 6.7 will ship 68esr in the www/firefox-esr port, then depending on the timeline of other releases and dependencies, might get updated (or not?) to 78esr when its released to stay on a supported branch, or stay on 68esr until this upstream branch dies. This situation happened in the past OpenBSD releases, where the www/firefox-esr and www/mozilla-firefox ports received updates as long as it was (humanly) possible (and i think i made it clear in all the cvs commit messages about what was to be expected).

I hope it cleared some things - in any case, if people care about -stable backports, give feedback to solene@.