[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Gnumed-update
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] Gnumed-update |
Date: |
Thu, 13 Aug 2009 13:16:55 +0200 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
On Wed, Aug 12, 2009 at 09:17:05PM -0700, Jim Busser wrote:
> 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,
That's easy to know (for the initiated, I know):
- bug fix releases at most require database fixups
- branch upgrades require a database upgrade (for the time being)
> the point is they cannot simply
> download the new client and expect it to work.
Within a branch - yes, they can. Across branches, no.
> In fact, I believe
> that new-branch clients will refuse to work with non-upgraded (non-
> new) database versions.
That's right.
> 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
For that reason I always release bug fix upgrades for both
client and database even if one of them doesn't contain true
changes.
> However can each of the other cases exist in
> isolation?
They can.
> 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?
yes
> 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.
That is configurable.
> 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."
This we already do.
> 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.)
>
> 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.
Based on this I have slightly improved the message.
> Therefore, while imperfect, I would certainly see the above as good-
> enough.
OK.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
- Re: [Gnumed-devel] Gnumed-update, (continued)
- Re: [Gnumed-devel] Gnumed-update, Karsten Hilbert, 2009/08/12
- Re: [Gnumed-devel] Gnumed-update, Jim Busser, 2009/08/13
- Re: [Gnumed-devel] Gnumed-update, Karsten Hilbert, 2009/08/13
- Re: [Gnumed-devel] Gnumed-update,
Karsten Hilbert <=
- Re: [Gnumed-devel] Gnumed-update, Jim Busser, 2009/08/13
- Re: [Gnumed-devel] Gnumed-update, Karsten Hilbert, 2009/08/13