Re: [Gnumed-devel] Re: versioning scheme

[Sebastian Hilbert]

On Mittwoch 24 September 2008, Gour wrote:

> Sebastian> The client goes from 0.3 to 0.4 for major changes and 0.3 to
> Sebastian> 0.3.2 for minor changes (no new features, only bugfixes)
>
> That's clear and logical.
>
> Sebastian> In my opinion in makes no sense to have server versions
> Sebastian> connected to client versions.
>
> Why not?
>
See below :-)

> Sebastian> I a year or so we will still be at v11 or so and the client
> Sebastian> will be 0.8 So in a few years the database probably changes
> Sebastian> very little to not at all and it makes no sense to increase
> Sebastian> the number when a new release is out.
>
> I do not understand what's wrong in having server at 0.8 as the client
> which clearly implies that in order to run 0.8.x client one requires 0.8
> server. otoh, v11 does not have any resemblance with 0.8.
>
Yeah but when we have client 1.3 and the database structure v9 which has not 
been changed why would we rename it if it did not change ?


> Sebastian> Please tell me where exactly the problem for the user and the
> Sebastian> admin is.
>
> The problem is that one has to go into Wiki or hunt some other resources
> in order to conclude which version of the server fits the specific
> client.

Not true. You are told when you start the client. You are told what version 
you have and what version is needed.

>
> That's good-enough reason for me ;)
>
Not for me :-)

How often are you going to bootstrap ? Once every few months. Come on. 

> Sebastian> If you start gnumed you are told explicetly what version you
> Sebastian> have and what version is expected. So if you are told that
> Sebastian> you have version 8 and need version 9 what problem is there
> Sebastian> to get version 9.
>
> Well, the whole bootstrap-procedure is, imho, messy...
>
> Bootstrapping from V2 to V3, from V3 to V4 etc.
>
Pardon me  ? 

> Why there must be this 'stepwise' bootstrap?
>
For the very reason that ensures that no data is lost or corrupted during 
updates. Come on., You bootstrap to the latest database excactly once and 
every few months there is an update.

If you want you can always bootstrap/restore a schema dump of the latest 
datbase.

But in this case please do not ask how to get rid of test data and the likes. 
If you bootstrap from scratch you have the option to leave out things you do 
not want right during bootstrap.

What you are really saying here is that it sucks to answer questions and put 
in the password during bootstrap.

There is a solution for you. Set the bootstrapper to "no questions asked mode" 
and supply the password via script or file. It won't ask you a thing and you 
won't even notice it bootstraps stepwise.

The v10 bootstrapper asks less passwords and can be set to silent (v8 and v9 
can do that as well).


> Why not adopt Postgresql-like procedure where the script in latest
> release can upgrade to the current release and having clear that if you
> want to run 0.4.x client you need 0.4 server. Simple and clear.
>
You can restore a dump for the latest and write a shell script called 
restore-latest-schema-from-dump.sh


> Let's not forget how many users GNUmed has atm, so not a big deal to
> sync server & the client and establish policy for future upgrades: if
> you want to stay with old client - fine, if not, you can upgrade both
> client & server to the new series being assured that all the X.Y.Z
> client will work with e.g. server's X series.

I fail to see what the name of the server package has to do with that except 
that it is more obvious that two version *might* be connected. What happens 
if an error is corrected in client 0.4.0 and server 0.4.0. The server package 
needs to be set to 0.4.1 and then I fail to see that both versions are 
connected.

I would be mislead into thinking that a client 0.4.1 is needed which is *not 
true*

By the way there is no point in right or wrong. One can freely name databases 
in the bootstrapper. So you are free to reflect your changes as there will 
users agreeing with your reasoning and maybe some with mine. 
>
> Once when the database format become more stable and the project reaches
> 1.0 there won't be (hopefully) so much changes and there won't be need
> to have lot of major increases in versions due to 'small fixes in
> database schema'.
>
> Sebastian> We could add a FAQ entry in the Wiki explaining what client
> Sebastian> version expects what server version.
>
> That is, imho, unnecessary and could be prevented by syncing versioning
> scheme.

No. See above.




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