Thank you for the Community News and for your continuing work on Sailfish OS!
I think it is a good thing to get changes out more often, especially if there are regressions.
However, I’m worried that releases seem to fill up the root partition. If this is a function of the number of releases, then fewer releases would be better. (I’m currently stuck on 4.4.0.58 for this reason and see no way forward but to reinstall, which is inconvenient.)
That’s definitely not a function of the number of releases. Well, not an intended one at least. In any case, please have a look at Storage Space | Sailfish OS Documentation. The article mostly talks about the home partition, but it provides some useful hints for investigating the root partition as well.
Personally, I’d like to see a more frequent release cycle that doesn’t require a feature barrage every time.
I just wonder what that would mean for the porters out there (and for maintaining the ports) if they have to run umpteen tests, make adjustments, etc. every month. Wouldn’t that diminish motivation?
A little suggestion for the repo roundup:
It would be nice if updates to the documentation would link to the actual doc page instead of the Pull Request.
I voted “Few major plus a few minor releases”, but that’s mostly because I don’t want to wait many months for fixes for very annoying issues, like battery drain (still an issue on 4.5.0 on my XA2), connectivity problems, sync problems and the likes. In many cases these are not even UI-releated, so no translation updates are required. In any case, I really prefer a more rolling release update of those updates, and leave the feature updates for the bigger releases, which you can then promote in all the media.
Ah, good point @nephros, I’ll do it like that next time when it applies : for instance when adding a new page or doing modifications in a single one. Thanks for the suggestion.
Really great Community Newsletter, good job.
I would also prefer minor releases as well. I think a regular updated system fits to a secure operating system.
I think that minor releases are important.
Introducing or surfacing bugs with each major release has proven inevitable. To my mind it is important to fix some of these with a prompt minor release, and then ideally a second bugfix/papercut release a while later. (I personally didn’t even consider installing the .16 release, but waited for the .18 to land)
With major release only strategy, you never have a release without minor or easily fixed bugs. A state of endless, rolling, bugginess and papercuts, due to successive major “upgrades”, is about the worst state software can be in.
One hybrid model could be small releases in ‘EA’ release mode, and major ones on the regular track.
Major or minor, as long as bugs filed by the community are smashed quickly & released (propose in a minor release) and when long standing missing features (of which some are very simple ones) are put on the roadmap & released (don’t always wait for major release, release them asap in a minor release) the positivity and usage by end users will grow.
Fundamentals to get right (of which some are missing at the moment, @Jolla):
1 - Communicate clearly to your users
2 - Have an open release schedule
3 - Be consistent and predictable
4 - Communicate changes regularly and transparently
5 - Get user feedback
The way the question was phrased was a bit too easy to answer for me. I read it as ‘do you want patches sooner’ without any implications. Why would someone want to deny that? Maybe because they find the ota upgrade process annoying… Or because they assume stuff would be breaking more often (i would think that smaller changes would actually help here)
However i wondered what that implies. Will that make development for jolla harder? Will bigger things be postponed because of that?
What about porters?
I only want to say yes without thinking much if it is for “free”. I do not really feel i can give an informed vote here
As I’ve said before in this forum, and the previous TJC, I’d rather have fewer major functionality releases and more bug fix releases to squash some pretty basic bugs that have been outstanding, in some cases, for years, without a fix in sight.
@rainemak, I would like to understand the purpose of this change, because as far as I understand it, it is rather detrimental for testing the SDK. I already asked at GitHub, but did not receive any reply yet.
For me it would be cool if the community could discuss the usability of the ui more straightforward.
Make a call fom contact app is a mess especially with 2 sim cards.
Edit: with one hand
Using the mail app is inconsistent from the ui philosophy. All swipes are not so logically.
Controlling the browser should be possible with swipes to.
All app shoul follow a central ui usability philosophy very strictly.
For me the UI was most consistent in during Jolla OS 2 / 3 …
Yes, the look & feel of SailfishOS and Jolla’s apps was best and most consistent at the time of SailfishOS 2. But definitely not any later than that: SailfishOS 3.0.0 actually brought the most awful changes and subsequent releases made the UI and its interactions even worse. It was indicated back then, that these changes were introduced to make the (only) corporate customer happy, but that customer (Rostelecom) is no longer one since the beginning of 2022.
Nevertheless, you sure can discuss or complain with others of “the community”, still I cannot see an incentive for Jolla to change anything (back), can you?
I feel very unconsistent that in the browser you cannot close all the open pages as you do on the main screen with the multitasking, pressing and swipyng down to close them all. There should be a common UI all over 
By the way, now that Aurora OS is over, can we please take back the pull-down menus in the email app? I still keep swiping down to send and get puzzled before remembering I have to look for the buttons below.
Keeping my hopes up to see the browser update to ESR 91 or 102 soon. We need a more current browser (gecko) version urgently.
IIRC one of the arguments of that change (and the reason for similar ui consistencies, e.g. in the browser) was that swiping and pulling gestures do not work well in combination with WebViews.
That of course could be easily solved or at least mitigated by defaulting to plaintext for email viewing (which would have the added benefit of being a major privacy improvement).