gnumed-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]