Library Changes in Upstream - how to react to developers

Platform Development
#1

I open this thread according to https://forum.sailfishos.org/t/sailfish-community-news-25th-february for further discussion

For me as a developer, it’s a bad thing to be presented with a fait accompli during early release.
Python changes do 3.8 - bam my application does not work anymore - and many others.
Just a new library release? Bam several apps (in openrepos!) uninstall because of missing libraries.
I would appreciate some news like: “We will have changes in openssl, python, libraries blabla which might break your solutions in the next release.” Then a developer will have time to react before the end user sees problems.
For me the early release is a test for the plattform itself. And most of the time the problems with own applications can only be found by guessing not by interpreting the changelogs. And some developers without the experience e.g. in python version changes or library bindings might have bigger problems why their code does not work anymore.

Yes, you only support harbour side libraries to be stable but only sort of. Thinking about PodQast/Gpodder IconMenus which did not work anymore because there were new elements in Silica with the new release. And the harbour concept does not really work, otherwise openrepos would not be necessary.

For a professional application handling there must be some instance for checking up, it the old stuff will work. There is a testing instance for new applications/application versions pushed into harbour. But there is no instance which checks the actually stored apps in harbour against new releases.

8 Likes
Idea: Development log for better communication
Sharing broken, will new file-sharing UI be allowed in 3rd party apps (4.2.0.19 EA)
#2

As things currently stand, as you mention in your post, Jolla doesn’t offer any guarantees about the compatibility of apps in OpenRepos. It’s a third-party repository which Jolla has no control over.

It’s different for the Jolla store. The rules for inclusion in the Jolla store are intended to minimise compatibility issues (amongst other things). It’s true there were some Silica changes recently which broke gPodder. As you may already know (but maybe not everyone reading this will do), it was discussed in the community meeting on 14th February. It turned out to be naming conflict: a new IconMenuItem was introduced to Silica which conflicted with a local name gPodder was using, and the suggested fix was for gPodder to use namespaces. See 4.l - 4.o in the meeting minutes. As Joona said during the meeting “We try to find intuitive, natural names for the new components so unfortunately these kind of risks hard to avoid”.

In general though, at least by my recollection, this sort of thing is really rare for apps in the Jolla store.

At the moment for OpenRepos, from what I understand, the best method for checking whether any particular app will be compatible with the next release, is to test it using the Early Access release. Could you explain why this isn’t working for you as an approach?

What I’m really interested to know is how you think this could be done better. Nobody (neither users nor developers) wants their app to become incompatible on the next OS upgrade. Is there some practical way that would make things easier for you, as a developer, to check whether your apps will be incompatible with the next release?

Just to be clear, this is a personal reply, none of this is necessarily representative of Jolla’s views.

3 Likes
#3

I think that people are generally just eager for Sailfish OS releases and thus enable Early Access. The eagerness outweighs possible breakage for them (myself) included, while Ealy Access should really be considered as a beta/pre-release.

A similar thing holds for OpenRepos. Everyone is aware that lots of useful apps are in there, because they cannot get through Harbour because of missing APIs (Pure Maps) or because they hook into system internals to provide extra functionalities (like MyBackups, or MPRIS for Podqast for example). In the end people want more functionality and flock to OpenRepos even though that also could be considered as just a testbed/development space.

In my opinion, removing barriers for Harbour and emphasizing EA more as a beta could help the situation.

I wish it would be possible to run some test suite on all Harbour apps, just like Rust compiles all crates on crates.io or Debian running autopkgtest on all packages before doing a release. But I cannot realistically see how that would work for GUI apps, but maybe someone is clever enough to think of a way. I know it is being done for web applications.

3 Likes
#4

Looking at the amount of crippled apps in the Jolla store does not indicate to me that compatibility issues are handled much better over there. I can speak from my own experience with apps in this case. Only allowing apps which use a limited amount of functionality of course helps when comparing to Openrepos.

In my experience it is always hard to find the breaking changes introduced. Sometimes I find some via IRC channels discussions (like what would happened to libcontextkit-statefs), git commits of a vague on-liner in a changelog. and above all your own research.

Let’s take the transition from gnu tools to busybox for example. Every release, more and more gnu tools are replaced by busybox. This breaks apps every release, not only in Openrepos, but also in the Jolla store (I can name Crest as a more recent example).
Not a single user is asking for this transition, and leads to frustrated reactions. Maybe if you would do an effort to explain why this is done (is it GPL licencing?), people would react less harsh and confused.

4 Likes
#5

Fully support adekker’s answer!
All said…

I do understand that it is not possible for Jolla to support full compatibility for ‘external’ openrepos.
But is is THE place to get up-to-date SW packages.
So informing developer base with more background about changes in advance would be helpful already. And not let them find line by line as adekker said.

Another example (as I was personally affected):
harbour-defender
The solution for the bootloop would have been so easy if I would have known that you introduced a new blocking systemd target (sailfish-unlock-agent) after the default.target!
Furthermore no one took notice that this is solved already and put in again same old note (indeed, may be true if taken from nodevel directly!).
And now you changed location of browser bookmarks as well as the cookies sqlite DB, without any notice. Breaking some users bookmarks and defender cookie handling. Exactly an example for more verbosity!
Another is the forgotten(?) nsswitch in sailjail config. Got recocognized relative early within the 7d time frame but was then reported as a bug (within idk 10 days?). …
Take above as examples for improvements in the information queue.

To add:
each new SFOS release now triggers lots of new/old bug reports, of which maybe a 10% (or even less) are solved before pushing out the public release (within a week).
And they might get solved within next release or not.
Why the rush?
You have the c-beta program (how many people?) but it seems that is not enough to trigger all new possibly introduced issues.
So maybe extend the beta or extend the EA time frame?

(personally: I stayed on 3.2 because all of this newly and not solved bugs in 3.3 / 3.4 and now again in 4.0. There are of course lots of workarounds and fixes later but my expectation of using a mobile device OS is not remembering new workarounds all 3-4 months.
Sorry for this little rant, was bit Offtopic)

1 Like
#6

Is this really different than any other Linux distro out there? Is there something, say Ubuntu does in this regard that you think Jolla should implement, or do you just hold Jolla to a higher standard?

I started going out on the same tangent as previous posters about OS breakages, but realized that’s (mostly) another matter altogether, so i will refrain from that.

1 Like
#7

Yes, there is.

At least I do receive almost every week small update packages solving this and that, fixing some security… and not a monolithic block that may fix some of the earlier introduced bugs (leaving other unfixed) and introduce new.
afair I had (almost) no package get broken when doing some update (even upgrade). Maybe too much standard user on Ubuntu? :wink:

Could be something to think about and optimize?

#8

For me Debian is the choice: You have stable for the brave and testing/unstable for the development. This works very good. I run bleeding edge (testing/unstable) on my daily use laptops. It is stable enough for me (more stable than some - say - enterprise distributions).

Breakages are small on package upgrades and you can react to them. And because you do not have a total break at a time you know what to do when you upgrade your stable machines to the next release.

And as an example for now: There is some efford to swap PodQast to sqlite3. I now found out that building the package with 4.0.1.48 SDK breaks compatibility to older versions. Actually I do not have a testing machine for 4.0.1.48 (because the only one is my productive XA2 and I do not want to break my podqast settings :wink:

Nevertheless if there is a dependency problem between 3.x and 4.x then also an infrastructure is needed to handle different versions.

How do the iOS people handle such problems: Get 14.3 or die?

#9

Right, but that is for fixes and point releases, no?
There are still major revisions and release upgrades, and they tend to break things for some people.
…and i guess the only way developers can match that is to be conservative in their dependencies and try the latest beta releases? Not all too different from what we have.

#10

Probably, or the latest versions of apps not being available on older version s of the OS.

#11

Doesn’t Apple always deploy a complete monolithic image with every update - fully replacing the previous iOS? And afaik there are a few broken apps - however, guidelines (not, it is not guidelines: rules) for entering the app store are very strict, i.e. devs only may use apis etc that are allowed by apple

#12

It seems some of the issues can be solved with better communication from Jolla to the community. I guess the weekly forum post is a first step.

A few suggestions:

  • Have a longer EA cycle. Say 2 weeks or more, to iron bugs and let developers prepare their apps for the new release, in particular when major changes occur. Or release a proper beta version a month before or so and let the EA be an RC before the stable release.
  • State more clearly that EA is beta/RC and may break. It’s there but reminding that in big font when it’s released will remind users that’s breakage may happen.
  • When new features or changes are confirmed to be included in the next release, and might require change in apps or break things, inform the dev community as early as possible so they can prepare their apps and/or give feedback.
3 Likes
#13

Sorry but hasn’t this been the purpose of EA since the begining??

And that if you want more breakage you can ask access to the C-Beta group??

#14

I honestly would go that far, that a EA cycle > 1 month is a must-do. Where you actually have time to fix bugs and devs have time to start working in 2 weeks from EA release bc they’re busy with other things. The microphone issue in Aliendalvik is unacceptable and I honestly probably stay on 3.4.

3 Likes
#15

Jolla could provide a system compose of the coming SFOS release beforehand (upstream). In form of the free version without Aliendalvik. This would allow developers to proactively adapt there apps. Maybe with a separated developer account/agreement? Such community involvement is done in the RedHat ecosystem right now. https://medium.com/swlh/centos-stream-why-its-awesome-5c45d944fb22

1 Like
#16

Imho I don’t like that and won’t do that:

  1. You don’t get any big notification with changelog anymore.
  2. I paid for my second device to get updates, no time for flashing.
#17

Just to chime in, since I helped debug the read only mount problem, it’d be nice to know if that change came about because of Jolla? or if it’s an android change specific to a port? I can help test, I even have 2 diffenent ports to work with, but have limited time.