The message to update the browser has been shared with the development team and should be handled as part of the next release. As mentioned previously, we cannot immediately switch to the latest builds or version patches, as the changes need to be validated with existing applications.
BTW, users with development skills can pitch in and make code changes and update applications. /e/OS being an open source project, all of us can only gain with the added skills of the community members. For now, they (users who want to make development changes) will need to approach the development team for requisite permissions.
For the future, we would definitely want to streamline and add a review /accept / reject/ merge changes process made by users, like it is on GitHub.
Update: This is a good suggestion. The team does not have any immediate plans on making updates available from the App Lounge. Such updates will definitely be a part of the future plans for the App Lounge.
The message to update the browser has been shared with the development team
The Chromium schedule and releases are public.
No project or company should have to be reminded to update such an extremely critical component of the system by its users.
Such updates will definitely be a part of the future plans for the App Lounge.
Unfortunately it is different, because /e/ ship a patched version of Bromite. So
the upstream updates need to be merged into /e/'s fork (which can be done automatically)
the changes need to be tested, which cannot be done automatically
then the update can be made available.
Once the upstream changes are merged and tested, they are not shipped until the next release of the whole OS.
They could be made available via App Lounge, but /e/ have chosen not to do that. The choice is probably historical, and is probably also based on lack of developers. Adding new features and fixing bugs in /e/'s code is given higher priority than shipping on upstream changes.
The same applies to all the forked apps - Mail, Messenger, Calendar, Account Manager, Notes. Upstream changes - whether new features, bug fixes or fixes for critical vulnerabilities - donât appear in /e/OS until the next release of the full system. Unfortunately, thatâs what happens when you choose to fork apps, rather than contributing upstream.
My response remains the same. If the intention is genuine and motivated by a desire to help users, then folks with the required technical skill can also step up and make the changes or updates to the /e/OS code. That is the whole idea of open source projects. The development team already has its hands full of the bugs in the Gitlab and does slip in a lot of places. Such cooperation will only help both DivestOS / /e/OS/ any other custom OS. We can either support and help each other grow, or snip and try to bring the other down.
Anyway, thanks for the reminder.