|
From: | Jim Busser |
Subject: | Re: [Gnumed-devel] Gnumed-update |
Date: | Wed, 12 Aug 2009 21:17:05 -0700 |
On 12-Aug-09, at 4:58 PM, Karsten Hilbert wrote:
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 databaseHowever is it also possible that we would ship a bug-fixed database which needs a "fixup" without any need for a bug-fixed client?
I notice that already 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. |
[Prev in Thread] | Current Thread | [Next in Thread] |