Release strategy for parallel release support, <4.0.0, armv7, etc

Applications
#1

It’s becoming a bit difficult to navigate the various requirements for releasing apps with the coming of Sailjail by force for harbour > 4.3. We also already have a situation where you need to compile explicitly for 3.4 armv7 to keep supporting installs to 3.4 from harbour. Some don’t care. I still do.

My thinking, to keep things somewhat simple has led me to begin branching for > 4.3 and 3.4 and under. For builds I was thinking of doing 4.3+ only builds for harbour and chum and keep the 3.4 and under branch builds on openrepos.

At the moment it means ‘melding’ between branches to track bugs in different releases. This is pita, but it is manageable. Just.

Does this sound like a strategy? Or should I ONLY put Sailjail++ stuff on harbour? After all, I lose all the nice support for old OSs with chum.

In any case, it’s a bunch of extra admin that is keeping me from REAL work. Your opinions and automation suggestions, please!

Thanks in advance.

4 Likes
#2

I tried verifying this, but couldn’t. I.e. SeaPrint 0.9.6 built with a then-latest SDK for all architectures still shows up and works just fine on 3.4. Could you elaborate a bit on what the problem is? Is it limited to apps depending on openssl, or what?

Seems like an odd grouping to me - wasn’t 3.4 when we got the new c(++) libs?

I struggle to care in general… but what i plain refuse to waste my time on is when people make up that some one minor bug makes SOFS completely unusable. 3.4 is the only version to be stuck on that is not self-inflicted, and it’s arguable how smart that is for much longer.
If i can support 3.4 without any faff, nice… but now passing 1 year since launch, i’m quite happy giving it one more major release and being done with it.

4 Likes
#3

I’ll take another crack with Tidings. I just did a bit of cleanup and can use it as a test case. I had the information from @slava and in IRC disscusion with, I believe, @lbt

Yeah, it’s arbitrary. It’s just been the case, until this week that a number of things which work fine on 3.4 don’t work on 4.3. This week updates came in that fixed the generic email accounts not working (which I need for work) and the browser issues (in part).

I’m working pretty hard to support 4.3 and am really happy to have Sailjail coming. In the main I’m just trying to come up with a provisional strategy for the interim. I’m well aware of the need to move security considerations to the fore. But I don’t want to leave people behind if I don’t have to.

One thing that also feels a bit off is that chum will build for everything from 3.1 up. Well, that has me beginning to disable build stanzas for the majority of builds where, for instance, Sailjail is involved. It’s just a lot of meta at the moment which is eating into my debugging/development time. But, it’s also just a matter of developing the right habits.

In general, I’m happy with the direction. I’m just unhappy with my lack of discipline in managing development. But I’ve been ‘solo’ for too long and am just really entering dev. with greater numbers of contributors in the last year.

But maybe someone also has some clever idea for packaging that makes this easier. I’m just lousy at writing spec files. Mastering those would probably make all this seem academic.

1 Like
#4

I’ve also been told that newest versions of my app don’t install on SFOS 3.x
It’s probably due to a minor change since the app is mainly in maintenance mode. But I found out that the newest SDKs only provide Kits and emulators for the latest SFOS versions so I can’t debug it without having to find old images/sdks :confused:

So I wonder, how do you compile/test your apps on SFOS 3.x?
Thanks.

1 Like
#5

You could use Chum OBS repos for it. That way it is easy to support large range of SFOS versions and users can install your app directly from there.

2 Likes
#6

Which app of yours?

I have two 3.4 devices and two 4.3 devices :slight_smile: I also installed the SDKs with 3.4 and 4.3 (the offline installer makes that ‘relatively’ painless.

Except for stuff that’s only available in 4.3 (like WebView) I’ve also found most things ‘just work’ also when compiled with the 4.3 arm sdk images.

Oh, and of course, I use chum/obs :slight_smile: Github repo direct to rpm is about as transparent as it gets. Hopefully we’ll get signing soon. But I do still test with the sdk on devices, first.

1 Like
#7

The app is BikeMe, but wait I do have a 3.4 device too, my Jolla 1 :slight_smile:
So it actually installs fine on 3.4, @olf tried on SFOS 3.2.1, which is probably not worth investing too much time :grimacing:

Thanks for the answers :ok_hand:

#8

Cool. I just cloned the code and it builds fine with the sdk 4.3 image but deploying arm to a 3.4 device. I’m not sure if everything works, but a log of things work :slight_smile: EDIT: on 3.4 no maps show up when, for instance, looking at a berlin co.

1 Like
#9

Oh that’s probably because by default it uses HERE and you need to set the tokens (https://github.com/sthocs/harbour-bikeme/blob/master/qml/pages/InteractiveMap.qml#L51)
What’s cool is that on 3.4, the osm plugin works (can be set in the settings) :slight_smile:

Anyway many thanks for taking the time to double check! I’ll stop polluting the topic ^^

#10

One last bit! On 3.4, selecting OSM was enough (and tinkering with providers) to get bikes showing in Berlin.

The SDK built 4.3 aarch64 installs fine. Select OSM works, too. However, tile loading seems a bit funky. Network errors appear. Still, mostly functional :slight_smile:

#11

NOTE: Sailjail config stuff and the location of configs/cache and so on ARE NOT a concern. You can install just fine on 3.4 with those. I consider the parallel release issue closed for my purposes.

1 Like
#12

However, tile loading seems a bit funky. Network errors appear.

Yeah I’ve replied on Github, Jolla broke the osm maps plugin with SFOS 4: Using QML map + osm not working?
I’ve let the option available because I was hoping it would be fixed soon enough :unamused:

I’ve tried to use the mapbox-gl-qml plugin yesterday to prepare the future but I wasn’t able to display anything on the map in a timely manner, copy-pasting the code from the example didn’t work as-is :see_no_evil:

#13

Thanks, I’ll have a look when I have a minute. I’m debugging some QML Location problems with Sailjail so it’s kinda ball-park :wink:

1 Like
#14

Please let me know what failed with mapbox-gl-qml plugin. Maybe some simple failing example? If you can, file an issue at the repository .

#15

It looks like it’s just an old default value for tile host. tile.openstreetmap.org is the new default according to: Tile servers - OpenStreetMap Wiki

I’m trying something like:

        Plugin {
            name: "osm"
            PluginParameter { name: "osm.useragent"; value: "harbour-bikeme" }
            PluginParameter { name: "osm.mapping.host"; value: "https://tile.openstreetmap.org" }
        }
#16

I’ve posted this in the github ticket, but here also in the hope that @rinigus has an idea:)

Adding the PluginParameter to set the osm.mapping.host

   Plugin {
       name: mapPlugin // dynamically set to osm
       parameters: [
                PluginParameter { name: "osm.mapping.host"; value: "https://tile.openstreetmap.org" },
                PluginParameter { name: "app_id"; value: "" },
                PluginParameter { name: "app_code"; value: "" }
            ]
   }

Seems to work (the old static host isn’t asked, but we get:

Cannot connect (null)::copyrightsChanged(QImage,QPoint) to QDeclarativeGeoMapCopyrightNotice::copyrightsChanged(QImage,QPoint)

#17

I don’t use those build-in Qt plugins as I switched over to vector tiles

#18

Ah, cool to know. Presumably to reduce bandwidth? Or better rendering?

#19

It is rendering using GPU, follows rotation of the device (no more labels upside-down), allows you to insert your own objects (like route or POIs) in addition to the ones given by tiles. For example, Pure Maps shows route under labels with street names. Those are few advantages of switching over to MapboxGL tiles

1 Like
#20

Haha I didn’t really want to ping you (yet), as I haven’t invested enough time (just copied the /// Location support part basically). I’ll take more time another day and start by trying to run the example, and ping you if needed, thanks :pray:

And thanks for the investigation @poetaster! (even though it should be Jolla’s role if they want more map-based apps) I didn’t meant to hijack the topic like that initially :smiley:

1 Like