Show current and latest auto_rx version on main page

[darksidelemm]

The current and latest version probably need to be made a bit more visible, so that users are reminded when there is an update available. Maybe there should also be some comparison that checks if the current version is older than the latest version and puts a note "update available" ?

[LukePrior]

I did consider this but never ended up adding it. You can modify the function used to fetch the latest version and check it against local and if they don't match push a new line to the log table. You would need to add some checks for people running beta versions etc.

[LukePrior]

I was thinking if you just wanted to get a quick fix you could change the colour of the log menu icon to red if there are any unread critical log messages.

[darksidelemm]

Hmm, I think the log probably moves a bit too fast for that. Having it on the top of the page is probably more likely to be seen.

[LukePrior]

Hmm, I think the log probably moves a bit too fast for that. Having it on the top of the page is probably more likely to be seen.

In that case, maybe we add the version number next to Radiosonde Auto-RX and do some special formatting if a newer version is available?

[LukePrior]

We could add a new line with Station and Current Task but that would just reduce available screen space.

[darksidelemm]

I reckon the version number to the right of the title is a good idea. Maybe add something like "(Update Available!)" in smaller text, with a link to the auto_rx releases page if something is available?

Checking for beta versions might be a little bit difficult. I do try and be consistent with beta version naming though, e.g. 1.5.2-beta1, so if the user has a version number with a '-' in the middle, you split, take the first part, and then compare that with the latest master branch version.

[LukePrior]

In terms of checking installed version vs latest version to see if an update is available I was thinking strip all text from the string which will get rid of beta tags and then also removes all dots so we get a string. i.e. 1.5.0 becomes 150 and 1.5.1 becomes 151, then we can just check if the latest version is larger. This will work fine but won't inform beta users of new beta versions, beta is harder as the current API implementation cannot see beta versions as it relies on releases.

[darksidelemm]

You could also possibly add the local version number and the master version number to a list, and sort alphabetically. This should discriminate between older and newer.

Actually the current way of checking the version just looks directly at the latest autorx/init.py on the master branch. It could also be made to look at the testing branch too....

[LukePrior]

Well we could check if the local version is beta or not then that would trigger a check of the latest version on master or testing branch. Master branch would be easy to check but with beta there a few edge cases which would need to be accounted for like if the latest version is now a stable release e.g. 1.5.1 and the user is on 1.5.1-beta3. The current code checks the releases page here is there a way to check for releases on the testing branch?

[darksidelemm]

Oh! I didn't realise thats how it worked... I don't remember writing that code!

The way it's done in the auto_Rx python code itself is here:
https://github.com/projecthorus/radiosonde_auto_rx/blob/master/auto_rx/autorx/utils.py#L62

It reads in https://raw.githubusercontent.com/projecthorus/radiosonde_auto_rx/master/auto_rx/autorx/__init__.py
and then looks for the version line.

You could do the same for the testing branch fairly easily by changing the URL. Could expose that function as a flask endpoint so it doesn't need to be run in the browser too (which is what I thought I was doing for some reason....).

Good point about the edge cases - the beta version one is a good one.

[LukePrior]

Oh! I didn't realise thats how it worked... I don't remember writing that code!

I didn't know we had a flask endpoint for it so I added it when redesigning the interface.

The way it's done in the auto_Rx python code itself is here:

These seems like a better way to do it, we can either go for two functions or one with an argument I'm not too sure how to get that bit working so I'll leave it to you.

Could expose that function as a flask endpoint so it doesn't need to be run in the browser too (which is what I thought I was doing for some reason....).

It will be good to get rid of another web request when the page is loading.

Good point about the edge cases - the beta version one is a good one.

Thinking about it we will need to check the master and testing branches in this situation and if a master branch release exists for that version it takes precedent, but that then introduces an issue of not notifying the user of future beta releases as it will think they want to stay on main releases. If you can think of a good logic system for handling it let me know.

[darksidelemm]

OK, so I'll add a flask endpoint (maybe /get_versions ) which does those requests and gets the version info for both the master and testing branches. Will think a bit more about the logic.

Won't get to this until Saturday morning at the earliest.

[LukePrior]

Won't get to this until Saturday morning at the earliest.

No rush I won't be able to work on the website until next week.

[ZigiWalter]

@darksidelemm, @LukePrior - thanks for your hard work!

A note regarding the above - in some old thread, Mark advised me to use a custom string for the version reported by radiosonde_auto_rx, as I'm running slightly modified code which may have its own bugs.

Currently, I simply concatenate a custom string (that includes numbers) to the "native" version in init.py:

__version__ = "1.5.1"
__version__ += "-<my_version_ID>"

Will the change you plan be friendly to such custom version strings?

[darksidelemm]

I guess i'll have to look specifically for 'beta' after the -, and compare based on that.
However if there is a newer master version number, then that will still report there being an update available.

@ZigiWalter I'm still not sure what your changes are?

[ZigiWalter]

Are you asking about code changes?
Mostly the ones discussed here: #252 (comment)

[ZigiWalter]

Oh, just recalled another change, where the customization of the version string came up: #254 (comment)

[darksidelemm]

OK, latest testing version (1.5.2-beta2) has an updated /get_version endpoint, which returns an object with 'current' and 'latest' fields. 'latest' will be set to either 'Latest', 'Unknown', or the version number of the newer version.

I've done the logic for comparing versions in the backend here: https://github.com/projecthorus/radiosonde_auto_rx/blob/testing/auto_rx/autorx/utils.py#L86

This should work in most cases I think, including @ZigiWalter's case (to a point - if that fork is from the latest testing branch, it wont necessarily show newer testing versions).

I've also update the current version display on the web interface: https://github.com/projecthorus/radiosonde_auto_rx/blob/testing/auto_rx/autorx/templates/index.html#L64

This info still needs to be moved to the top of the main page - I'll leave that bit to you @LukePrior

@ZigiWalter I'll have to take a look at your fork at some point and see how it can be integrated into the main auto_rx repo... Any kind of 'skip' mode would need to be something enabled optionally.

[LukePrior]

I think this can be closed now?