idea (librewolf beta) #2762

ddsss5 commented 2025年12月22日 08:23:10 +01:00

idk i think having librwolf beta would be good, especially for testing. Bugs would be patched way faster

idk i think having librwolf beta would be good, especially for testing. Bugs would be patched way faster

any1here commented 2025年12月22日 14:47:49 +01:00

I talked about this on Matrix a few days ago, and it is something being considered for the future.

I talked about this on Matrix a few days ago, and it is something being considered for the future.

hsza commented 2025年12月22日 17:17:33 +01:00

I would use a version of librewolf based on mozilla's beta branch

I would use a version of librewolf based on mozilla's beta branch

alyx161 commented 2025年12月22日 17:36:26 +01:00

Currently thinking about this as well.

I am leaning more toward something like a LibreWolf nightly or experimental?
For example, not really our own beta release, but rather the latest Firefox beta with our patches applied.

We could automate this in the CI.
This way it would not add any additional maintenance burden. It might even help us, since we would notice early if a build fails due to upstream changes. It would also allow people to easily poke around early builds to check whether new features, including AI related ones, slipped through and need attention from our side.

That said, I would avoid calling it a LibreWolf Beta, even if it is based on the Firefox Beta. The term beta usually implies some readiness and that some basic testing has already been done, which we probably would increase the maintenance burden a lot.

Currently thinking about this as well. I am leaning more toward something like a LibreWolf nightly or experimental? For example, not really our own beta release, but rather the latest Firefox beta with our patches applied. We could automate this in the CI. This way it would not add any additional maintenance burden. It might even help us, since we would notice early if a build fails due to upstream changes. It would also allow people to easily poke around early builds to check whether new features, including AI related ones, slipped through and need attention from our side. That said, I would avoid calling it a LibreWolf Beta, even if it is based on the Firefox Beta. The term beta usually implies some readiness and that some basic testing has already been done, which we probably would increase the maintenance burden a lot.

alyx161 commented 2026年01月03日 18:55:02 +01:00

As a small update, we're currently moving the CI from GitLab to Codeberg.
Once that is done and working, I will add a workflow which should produce nightly builds 🙂

As a small update, we're currently moving the CI from GitLab to Codeberg. Once that is done and working, I will add a workflow which should produce nightly builds 🙂

eclecRC commented 2026年01月04日 19:04:26 +01:00

That's wonderful news! User-testable nightly builds to identify and whack out undesirable features/AI bloat will certainly be nice.

I'm going to throw the opposite idea out here though: What about an ESR branch circa 153.x down the line? This would add some predictability about feature creep and userChrome stability, granted nightly build testing should reach that same end.

That's wonderful news! User-testable nightly builds to identify and whack out undesirable features/AI bloat will certainly be nice. I'm going to throw the opposite idea out here though: What about an ESR branch circa 153.x down the line? This would add some predictability about feature creep and userChrome stability, granted nightly build testing should reach that same end.

hsza commented 2026年01月04日 19:24:29 +01:00

granted nightly build testing should reach that same end.

yea i don't think there'd be any point

> granted nightly build testing should reach that same end. yea i don't think there'd be any point

alyx161 commented 2026年01月04日 19:24:58 +01:00

@eclecRC wrote in #2762 (comment):

I'm going to throw the opposite idea out here though: What about an ESR branch circa 153.x down the line? This would add some predictability about feature creep and userChrome stability, granted nightly build testing should reach that same end.

ESR builds are probably out of scope for now.
The thing about nightly builds is that they don't add any extra work. They get build automatically. If something fails, this is a heads-up for us what we need to fix before the next release.
If something doesn't work in a build, if a build breaks something drastically that is fine. Those builds are not made so people use them as a daily driver. They are there so everyone can poke around a test build based on the current state of things.

ESRs on the other-hand is something we would need to actively maintain. Something people would choose because its suppose to be more stable, and something that people expect to work.

@eclecRC wrote in https://codeberg.org/librewolf/issues/issues/2762#issuecomment-9540473: > I'm going to throw the opposite idea out here though: What about an ESR branch circa 153.x down the line? This would add some predictability about feature creep and userChrome stability, granted nightly build testing should reach that same end. ESR builds are probably out of scope for now. The thing about nightly builds is that they don't add any extra work. They get build automatically. If something fails, this is a heads-up for us what we need to fix before the next release. If something doesn't work in a build, if a build breaks something drastically that is fine. Those builds are not made so people use them as a daily driver. They are there so everyone can poke around a test build based on the current state of things. ESRs on the other-hand is something we would need to actively maintain. Something people would choose because its suppose to be more stable, and something that people expect to work.

eclecRC commented 2026年01月04日 19:50:37 +01:00

@alyx161 wrote in #2762 (comment):

ESR builds are probably out of scope for now. The thing about nightly builds is that they don't add any extra work. They get build automatically. If something fails, this is a heads-up for us what we need to fix before the next release. If something doesn't work in a build, if a build breaks something drastically that is fine. Those builds are not made so people use them as a daily driver. They are there so everyone can poke around a test build based on the current state of things.

ESRs on the other-hand is something we would need to actively maintain. Something people would choose because its suppose to be more stable, and something that people expect to work.

That's quite fair. I presume these nightly builds would come in the form of a tarball for Linux? Will they default to a separate profile directory from release-LW?

@alyx161 wrote in https://codeberg.org/librewolf/issues/issues/2762#issuecomment-9540905: > ESR builds are probably out of scope for now. The thing about nightly builds is that they don't add any extra work. They get build automatically. If something fails, this is a heads-up for us what we need to fix before the next release. If something doesn't work in a build, if a build breaks something drastically that is fine. Those builds are not made so people use them as a daily driver. They are there so everyone can poke around a test build based on the current state of things. > > ESRs on the other-hand is something we would need to actively maintain. Something people would choose because its suppose to be more stable, and something that people expect to work. That's quite fair. I presume these nightly builds would come in the form of a tarball for Linux? Will they default to a separate profile directory from release-LW?

friendlyuser commented 2026年02月02日 16:00:36 +01:00

(note that these are mostly related to gentoo, other distros may be also affected by this, although i am unable to verify)

commenting here since i could not find a relevant issue regarding a potential ESR release (a discussion issue could be created around this, if needed), but if i were to install librewolf-147.0.1_p3.ebuild (as of the making of this comment), i would need to keyword the following packages:

dev-libs/nss ~amd64
dev-libs/nspr ~amd64
dev-libs/icu ~amd64

dev-libs/icu being the worst one, since it requires rebuilding all reverse dependencies:

 (dev-libs/icu-78.2:0/78::gentoo, ebuild scheduled for merge) causes rebuilds for:
 (media-libs/raptor-2.0.16-r1:2/2::gentoo, ebuild scheduled for merge)
 (dev-libs/boost-1.88.0-r1:0/1.88.0::gentoo, ebuild scheduled for merge)
 (dev-qt/qtbase-6.10.1:6/6.10.1::gentoo, ebuild scheduled for merge)
 (sci-libs/libqalculate-5.8.2:0/23.3::gentoo, ebuild scheduled for merge)
 (dev-qt/qtcore-5.15.18:5/5.15.18::gentoo, ebuild scheduled for merge)
 (dev-libs/libxml2-2.15.1:2/16::gentoo, ebuild scheduled for merge)
 (app-text/libebook-0.1.3-r4:0/0::gentoo, ebuild scheduled for merge)
 (kde-plasma/plasma-workspace-6.5.5-r1:6/6::gentoo, ebuild scheduled for merge)
 (media-libs/harfbuzz-12.2.0:0/6.0.0::gentoo, ebuild scheduled for merge)
 (dev-qt/qt5compat-6.10.1:6/6.10.1::gentoo, ebuild scheduled for merge)
 (app-text/libqxp-0.0.2:0/0::gentoo, ebuild scheduled for merge)
 (dev-libs/xerces-c-3.3.0:0/3.3::gentoo, ebuild scheduled for merge)
 (media-libs/libcdr-0.1.8:0/0::gentoo, ebuild scheduled for merge)
 (net-libs/nodejs-22.13.1:0/22::gentoo, ebuild scheduled for merge)
 (kde-plasma/kdeplasma-addons-6.5.5-r1:6/6::gentoo, ebuild scheduled for merge)
 (dev-libs/libical-3.0.20-r2:0/3::gentoo, ebuild scheduled for merge)
 (app-office/libreoffice-25.2.7.2-r1:0/0::gentoo, ebuild scheduled for merge)
 (app-text/libmspub-0.1.4:0/0::gentoo, ebuild scheduled for merge)
 (kde-apps/konsole-25.08.3:6/6::gentoo, ebuild scheduled for merge)
 (dev-db/sqlite-3.50.4:3/3::gentoo, ebuild scheduled for merge)
 (media-libs/libzmf-0.0.2-r1:0/0::gentoo, ebuild scheduled for merge)
 (media-libs/libvisio-0.1.10:0/0::gentoo, ebuild scheduled for merge)

@alyx161 wrote in #2762 (comment):

ESRs on the other-hand is something we would need to actively maintain.

could i ask why would this be exactly? as i see it, no changes would need to be made until esr gets upgraded to a newer version, which would only require copy pasting patches and settings from rapid until the next.

(note that these are mostly related to gentoo, other distros may be also affected by this, although i am unable to verify) commenting here since i could not find a relevant issue regarding a potential ESR release (a discussion issue could be created around this, if needed), but if i were to install `librewolf-147.0.1_p3.ebuild` (as of the making of this comment), i would need to keyword the following packages: ``` dev-libs/nss ~amd64 dev-libs/nspr ~amd64 dev-libs/icu ~amd64 ``` dev-libs/icu being the worst one, since it requires rebuilding all reverse dependencies: ``` (dev-libs/icu-78.2:0/78::gentoo, ebuild scheduled for merge) causes rebuilds for: (media-libs/raptor-2.0.16-r1:2/2::gentoo, ebuild scheduled for merge) (dev-libs/boost-1.88.0-r1:0/1.88.0::gentoo, ebuild scheduled for merge) (dev-qt/qtbase-6.10.1:6/6.10.1::gentoo, ebuild scheduled for merge) (sci-libs/libqalculate-5.8.2:0/23.3::gentoo, ebuild scheduled for merge) (dev-qt/qtcore-5.15.18:5/5.15.18::gentoo, ebuild scheduled for merge) (dev-libs/libxml2-2.15.1:2/16::gentoo, ebuild scheduled for merge) (app-text/libebook-0.1.3-r4:0/0::gentoo, ebuild scheduled for merge) (kde-plasma/plasma-workspace-6.5.5-r1:6/6::gentoo, ebuild scheduled for merge) (media-libs/harfbuzz-12.2.0:0/6.0.0::gentoo, ebuild scheduled for merge) (dev-qt/qt5compat-6.10.1:6/6.10.1::gentoo, ebuild scheduled for merge) (app-text/libqxp-0.0.2:0/0::gentoo, ebuild scheduled for merge) (dev-libs/xerces-c-3.3.0:0/3.3::gentoo, ebuild scheduled for merge) (media-libs/libcdr-0.1.8:0/0::gentoo, ebuild scheduled for merge) (net-libs/nodejs-22.13.1:0/22::gentoo, ebuild scheduled for merge) (kde-plasma/kdeplasma-addons-6.5.5-r1:6/6::gentoo, ebuild scheduled for merge) (dev-libs/libical-3.0.20-r2:0/3::gentoo, ebuild scheduled for merge) (app-office/libreoffice-25.2.7.2-r1:0/0::gentoo, ebuild scheduled for merge) (app-text/libmspub-0.1.4:0/0::gentoo, ebuild scheduled for merge) (kde-apps/konsole-25.08.3:6/6::gentoo, ebuild scheduled for merge) (dev-db/sqlite-3.50.4:3/3::gentoo, ebuild scheduled for merge) (media-libs/libzmf-0.0.2-r1:0/0::gentoo, ebuild scheduled for merge) (media-libs/libvisio-0.1.10:0/0::gentoo, ebuild scheduled for merge) ``` @alyx161 wrote in https://codeberg.org/librewolf/issues/issues/2762#issuecomment-9540905: > ESRs on the other-hand is something we would need to actively maintain. could i ask why would this be exactly? as i see it, no changes would need to be made until esr gets upgraded to a newer version, which would only require copy pasting patches and settings from rapid until the next.

TheGreatMcPain commented 2026年05月01日 22:09:15 +02:00

@friendlyuser Is -system-icu not working for www-client/librewolf?

@friendlyuser Is `-system-icu` not working for `www-client/librewolf`?

friendlyuser commented 2026年05月02日 13:57:09 +02:00

@TheGreatMcPain wrote in #2762 (comment):

@friendlyuser Is -system-icu not working for www-client/librewolf?

im using system-* use flags globally, so i can't say for sure (compiling librewolf takes too long for me to test), but disabling a use flag seems more like a temporary workaround, rather than a proper solution.

there should probably be a separate issue for the discussion of an esr release and if its worth it/enough interest in it (not for gentoo, but in general).

@TheGreatMcPain wrote in https://codeberg.org/librewolf/issues/issues/2762#issuecomment-14157920: > @friendlyuser Is `-system-icu` not working for `www-client/librewolf`? im using system-* use flags globally, so i can't say for sure (compiling librewolf takes too long for me to test), but disabling a use flag seems more like a temporary workaround, rather than a proper solution. there should probably be a separate issue for the discussion of an esr release and if its worth it/enough interest in it (not for gentoo, but in general).