Iceraven-browser: Track Mozilla's stable release branches instead of their master branch to let them fix their regressions themselves before we ship them
What is the user problem or growth opportunity you want to see solved?
For now it seems that iceraven is based on firefox nightly which is not suitable for daily usage. It would be better to have beta and release channels.
How do you know that this problem exists today? Why is this important?
I encountered some bugs in iceraven which are regression on firefox nightly.
Who will benefit from it?
Users who want a more stable browser.
linsui
All 4 comments
I suppose I partially agree with one aspect of this request, but not others.
I think having several release channels is premature given the likely relatively modest size of our userbase. We need everyone reporting bugs on the same browser version to provide the best possible experience right now, and the maintaining three channels seems like a complication and an unnecessary burden on our maintainers at this point in the browser's development. It could also confuse some users.
I also think because of the state Mozilla released Fenix in (i.e. devoid of features and options), there is some temporary value in reaching to nightly and/or beta to grab features and options that may not hit their stable branch for a while or may never hit their stable branch.
However, once the upstream Mozilla Fenix becomes feature complete as they understand it (I suspect it will never be feature complete as we would understand it, which is part of the point of the fork), at that juncture I would support switching over to being based on the stable version of that browser plus all the Iceraven distinctive coding and features, some of which would include a few nightly features that Mozilla refuses to migrate to their stable version.
Right now, as I understand the state of things, we are using the stable rendering engine with nightly code, plus our own code, around it, right? So, it's not quite correct to say that we are a fork of nightly. We're using the most stable thing they did (the rendering engine) in its most stable form. The problem is that they have not committed enough features to the stable branch to use that as a base for everything yet. I do see that type of transition as a long-term goal we should have once they have, though.
My assumption has always been that we would eventually be based on stable, but I am not in charge or doing the coding, and no one has ever said anything, so it has always just been assumption. I figured the current situation was because of how lacking the stable Firefox is right now and that we would have less and less nightly code as time passes.
CharmCityCrab
on 22 Sep 2020
We're kind of a nightly/stable hybrid at the moment. We ship the stable rendering engine, but we also pull in Mozilla's changes from Firefox's master branch as they happen, without the benefit of their slow release branch testing and only-taking-bugfixes-for-a-while process. This lets us ship features that are missing vs. Fennec quickly if Mozilla brings them back, and it makes the Git synchronization easier, but it's definitely a source of bugs.
We could try not pulling from Mozilla master anymore but instead merging in changes periodically from their current release branch. The commits they make on the release branches are not designed to share a Git history with later development, however, so the Git state could get ugly with multiple copies of bugfix commits (fix in master and back port to last release).
interfect
on 23 Sep 2020
It may not be too difficult for us to keep track of mozilla's release branches as well. We can continue to merge mozilla-mobile/fenix master branch to our fork branch to keep it up to date. But whenever mozilla creates a release/beta branch from master, we could rebase those branches as well to the appropriate part in our commit history and create a release from there. May be we can do beta branches as they are more up-to-date than release. We could try this and see if it is worth the while.
abhijitvalluri
on 24 Sep 2020
That's an idea. I think we should try it.
interfect
on 25 Sep 2020
Related issues
ale82to
路
9Comments
interfect
路
5Comments
aquaspy
路
10Comments
sheikh-azharuddin
路
5Comments
kufue
路
4Comments
Most helpful comment
I suppose I partially agree with one aspect of this request, but not others.
I think having several release channels is premature given the likely relatively modest size of our userbase. We need everyone reporting bugs on the same browser version to provide the best possible experience right now, and the maintaining three channels seems like a complication and an unnecessary burden on our maintainers at this point in the browser's development. It could also confuse some users.
I also think because of the state Mozilla released Fenix in (i.e. devoid of features and options), there is some temporary value in reaching to nightly and/or beta to grab features and options that may not hit their stable branch for a while or may never hit their stable branch.
However, once the upstream Mozilla Fenix becomes feature complete as they understand it (I suspect it will never be feature complete as we would understand it, which is part of the point of the fork), at that juncture I would support switching over to being based on the stable version of that browser plus all the Iceraven distinctive coding and features, some of which would include a few nightly features that Mozilla refuses to migrate to their stable version.
Right now, as I understand the state of things, we are using the stable rendering engine with nightly code, plus our own code, around it, right? So, it's not quite correct to say that we are a fork of nightly. We're using the most stable thing they did (the rendering engine) in its most stable form. The problem is that they have not committed enough features to the stable branch to use that as a base for everything yet. I do see that type of transition as a long-term goal we should have once they have, though.
My assumption has always been that we would eventually be based on stable, but I am not in charge or doing the coding, and no one has ever said anything, so it has always just been assumption. I figured the current situation was because of how lacking the stable Firefox is right now and that we would have less and less nightly code as time passes.