Re: [Gnumed-devel] Gnumed-update

[Jim Busser]

On 12-Aug-09, at 4:58 PM, Karsten Hilbert wrote:

Important to these strings would be to

- include mention when a database fixup would be needed

It already does - as far as major releases are concerned.

A major release involves not a database fixup but (rather) a database *upgrade*, correct?

From the point of view of the regular user, I mainly want them to be aware that in the event that whether it is a database fixup or a database upgrade that is required, the point is they cannot simply download the new client and expect it to work. In fact, I believe that new-branch clients will refuse to work with non-upgraded (non-new) database versions.

What I am less sure is the interaction, within a branch, of a minor updated (or bug-fixed) client and a database that may or may not have required a fixup. I can imagine a situation where it would be important for data integrity for a bug-fixed client and a bug-fixed database upgrade to part of a single release where both parts will be needed together. However can  each of the other cases exist in isolation? I can imagine that

- a bug-fixed client may be able/allowed to connect to an unaltered database

- a minor-upgraded client may be able/allowed to connect to an unaltered database

However is it also possible that we would ship a bug-fixed database which needs a "fixup" without any need for a bug-fixed client?

- truncate to one line by appending [and more]

The dialog could say:

0.4.x – *database fixup required* + blah blah

0.4.7 – fixes measurements grid, document translations [and more]

0.4.6 – fixes update-available message, document search

0.4.5 – running…

(may as well compare to what is running, and signal this in the dialog)

What if I am running 0.3.11 ? There's both 0.3.12 and 0.4.7.

I notice that already

http://www.gnumed.de/downloads/gnumed-versions.txt

reports on the existence of release candidates, which might only be appropriate to testers of earlier within-branch release candidates. I had thought (maybe incorrectly) that we were notifying only of in-branch updates. I had understood that it might have been because a new-branch client will not be usable in isolation (without) a database upgrade. Maybe at the point where a higher-branch client becomes available, there is little point specifying the details and only advising the user that

"a new version of GNUmed (which will require database modification) is available."

In fact I would point out that since the client cannot give notification without an Internet connection, and an internet connection gives the capacity to check a web page, why not spare ourselves the details of the notification and simply report either:

0.4.5 – running…

No new updates in this branch. (or: No new updates.)

^^ above depends how to resolve within-branch only, or across-branch

or 0.X.x available. Noncritical. (or: *Critical*). Click <link> for details.

Database modification *will* be required. (or: No database modification required.)

0.Y.y running.

Already I know that 0.X.x string management would be simple *only* in the case where any criticality -- and requirement for a database modification -- would be relative to 0.X.x - 1 despite that there may have been additional updates between it and 0.Y.y.

I propose that it is no matter. In my view, those who use GNUmed in production will start clients often enough that even intermittent internet connections are likely to disclose at least one instance of each update. It would be uncommon (if not outright rare) to put out more than one upgrade per week and if users have such intermittent usage of GNUmed or internet connections then this reliance would fail anyway and their maintainer should have to be on some email list.

Therefore, while imperfect, I would certainly see the above as good-enough.