This post contains the detailed changelog entries of Sailfish OS update 4.1.0.24 compared to 4.0.1.48.
Since the log is too long (3000 lines) for forum.sailfishos.org to understand (as html), we have attached it as a simple text file for you:
Changelog_from_4.0.1.48_to_4.1.0.24.final.md (174.3 KB)
Changelog_from_4.0.1.48_to_4.1.0.24.final.txt (174.3 KB)
The corresponding release notes are here: https://forum.sailfishos.org/t/release-notes-kvarken-4-1-0/5942.
Could you please change extension to .md (markdown)? Okular (and SFOS Office?) will then open and render it as such.
Wow, reading them as markdown makes the changelogs so much more readable! Thank you!
The greatest news are the improvements/fixes for calendars, Android (Signal / contacts), and support of offline MLS (GPS).
mkcal-qt5
- Updated : 0.5.25-1.2.14.jolla – 0.5.34-1.3.4.jolla
Hi, how can I use the new API (e.g. ExtendedCalendar change) in a way that I can also run on 4.0.1?
I imagine I can update mkcal-qt5 to 0.5.34 on the 4.0.1 build VM, but zypper ref / up does not seem to find anything new.
Is there any conf change I should make for a 4.0.1 build vm to be able to upgrade such packages?
Too bad the new Sailfish OS release came earlier than the SDL 2.0.16 release, which will likely be released on May 21st. The new release contains at least one nice-to-have fix for a bug, which had to be worked around for now on Sailfish OS.
Anyway, better luck next update hopefully 
“Sorry, the file you are trying to upload is not authorized (authorized extensions: jpg, jpeg, png, gif, heic, heif, txt).”
You will habe to compile it yourself on 4.0.1. There is no build of 0.5.34 done for 4.0.1. May I ask out of curiosity why do you need the latest version on 4.0.1 ?
I guess forum admin can change that?
Thanks @dcaliste for the answer.
I was trying to make Amazfish run on 4.1.0 (I am not the author, of course) and noticed this unavailable symbol when (after adding some libicu links) : _ZN5mKCal16ExtendedCalendarC1ERK7QString
So my first thought was, cool, let’s use another ExtendedCalendar constructor, that’s common between the two mkcal versions. Unfortunately there isn’t a such common API.
So I was thinking - how would one fix this, if you’d like to release both for SFOS 4.0 and 4.1? Maybe packages could be upgraded on the older release too. Unfortunately they aren’t, either - admittedly it would cause breakages on 4.0 if it would update…
So I think the problem is that the mkcal API is not in any way compatible between these two sampled versions, nor forward or backward.
This was before 4.1 target was released. Compiling on 4.1 should fix it for me, but I what is the solution in general for these kind of situations?
In this situation, the only option is for me to provide builds for 4.1, and 4.0 (and older releases as they have different icu versions too)
Ok, I remember now the change in mKCal. The API was not modified and is backward compatible, but there is a break in ABI (thus your issue when loading the dynamic library). I introduced this break when changing the inheritance scheme of ExtendedCalendar in mKCal. It is now based on KCalendarCore::MemoryCalendar and not KCalendarCore::Calendar anymore. This saved hundreds of duplicated lines in mKCal.
I’m afraid there is no direct way to make a compilation in SDK for 4.0.1 to run on both 4.0.1 version and 4.1.0, because of this ABI break. You cannot have an executable that will can be compiled to use either the Calendar inheritance or the MemoryCalendar one.
Thanks @dcaliste for the detailed explanation. I guess it is what it is, apps are going to be tied per OS version (at least in this case). This might be more bothersome for ports, where an updated OS version might not be available as soon as Jolla releases it.