Re: [Gnumed-devel] Re: versioning scheme

[Sebastian Hilbert]

On Mittwoch 24 September 2008, Gour wrote:
> >>>>> "James" == James Busser <address@hidden> writes:
>
> James> what client versioning number means to users.
>
> What database format means to users :-)
>
> James> Presently it is the 0.3 level (first decimal place) which is the
> James> major version thus a forcing up to 0.4 implies a major
> James> enhancement to what the client can do when the needed database
> James> change only enabled something small like non- mandatory date of
> James> birth
>
> Breaking format of the database is, imho, of major concern no matter how
> big/small the change is.
>
> To do it less often, it means more time has to be spend planning future
> releases.
>
> Take a look around and you will see that breaking of 'API' does not
> justify 'minor-upgrade' only.
>
> James> the scripting presumably parses whole numbers to the right of "v"
> James> and if there are people however few already in production with
> James> v<whole
> number> it may be an impossibility to change to v_0.4 without a lot
> James> of manual work. This should wait for some extra discussion.
>
> There is some way for sure, and scripts can be changed. It's better,
> imho, to spend time fixing the scripts than to continue confusing
> end-users.

I personally fail to see the confusion. Please elaborate a case where a user 
could be led to false conclusions and is unable to get GNUmed running in a 
suitable client database configuration.

If you are talking about config files that point to version 8 databases when 
they should reflect an update to v9 database because of updated to client 
0.3.2 one could argue that is the job of the packager to make sure that the 
user is informed of new config files and the user will be told on startup 
that is is the wrong verison.

We should add text to the notification on the wrong version that a user might 
have to update the config file.

This problem is not solved by renaming database versions. It is only solved by 
getting rid of version names alltogether which we will not support as it will 
break everything pretty soon.

>
> James> If it might help, I have added database version info to the page
>
> James>        http://wiki.gnumed.de/bin/view/Gnumed/ReleaseStatus
>
> Let's hope we'll get rid of this info in the future ;)
>
I hope so too. One way is to make use of the info about the mismatch and 
enhance it to maybe upgrade, bootstrap or whatever the correct version and 
change the config file.

In the future client version will change every six months. So I hope it will 
be enough to have a note along with the release notes that the database needs 
to be upgraded.

It admins and users do not want to read that info the are on their own. I 
welcome any patches that build a config file editor for GNUmed ( I have alway 
dreamt of that) This editor can be called from the login gui. It could even 
have a feature to produce new profiles

>
> Sincerely,
> Gour



-- 
Sebastian Hilbert 
Leipzig / Germany
[www.gnumed.de]  -> PGP welcome, HTML ->/dev/null