Hi Dirk.
On 8/12/23 08:21, Dirk Hohndel via subsurface wrote:
As Michael and I try to improve the way we post binaries for people to
test and use, following up on the Ubuntu and Fedora binaries I
mentioned earlier, we now have binaries posted on GitHub as "daily" or
"latest" releases:
https://github.com/subsurface/subsurface/releases/tag/latest
There is an oddity about the way this works. GitHub only does releases
for tags. So there are basically two options:
(a) do a "latest" tag and post all the binaries under that (which is
what I've done so far)
(b) create a tag for every merge / push to the master branch
Both have drawbacks:
(a) creates a real mess with quickly having many, many artifacts in
that same 'latest' release and the user having to figure out which
ones to download.
(b) creates a real mess as the git repo gets flooded with new tags -
but then the releases themselves look much more sane
I'm curious what people think would be the better strategy - or if
there's a third option that I've missed.
I have used (b) in the past, and gone for a concatenation of a
datestring with a counter - this results in release numbers that make it
obvious how recent they are, which is an advantage when trying to help
people reporting a problem. It also seems to be possible to create
release with an indicative name without having to add it as a tag in the
repository - at least when using GitHub actions to create the release:
https://github.com/betaflight/betaflight-configurator/blob/07da3398426b5d6f1e0bd74d37f0e6f0cd622c39/.github/workflows/nightly.yml#L55
This is how the releases created by this look like:
https://github.com/betaflight/betaflight-configurator-nightlies/releases
I'd also appreciate if people could try these new and improved Windows
builds (they use a fresh build container with the very latest Qt5.15
libraries, newer compiler, and several other newer dependencies
compared to those that I posted last week. I'd be especially
interested if there are any improvements to BT / BLE handling, as
there were numerous updates to the corresponding code in Qt.
The Windows version of build 262 is working just fine in a VM running
Windows 10.
And I'd love to know how the Android APK works for people trying to
side-load Subsurface-mobile onto an Android device.
In one quick test for me it seemed to be fine (if awkward and
annoying) - but I'd love to make sure a few more people with
non-Google devices try this (for reasons of personal preferences I
only tend to use plain Google Android devices... therefore I'd love to
make sure that this works with Samsung or <insert other brands>
devices as well.
The APK version of build 262 works just fine for me on an older Xiaomi
Redmi Note 7 running Android 10.
The app looking hung could be the initial connection / initial
download from the cloud. There isn't enough visual feedback for that.
This is only a problem if you have to uninstall the app and then
re-install - like when moving from the store app to a sideloaded version
and encountering a new signing key because of this. If we manage to use
the same signing for all of our nightly builds people will be able to
upgrade between them without a uninstall / reinstall, and avoid having
to re-authenticate and re-download.
But I'm not planning to do any UI changes until we have things working
with Qt6 which will be a while.
Maybe a 'quick win' temporary fix for this would be to add a warning
about this to the 'Testing cloud credentials' prompt?
https://github.com/subsurface/subsurface/blob/e26dd301656400e1355fad7bac158fe48aa6b868/mobile-widgets/qmlmanager.cpp#L692
Cheers
Michael Keller
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
