[Gnumed-devel] Re: versioning scheme

[Gour]

>>>>> "Sebastian" == Sebastian Hilbert <address@hidden> writes:

Sebastian> The versioning has the following format. If any changes to
Sebastian> the table structure are made a new version will be released
Sebastian> like v10 v11 and so forth

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?

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.

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.

That's good-enough reason for me ;)

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.

Why there must be this 'stepwise' bootstrap?

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.

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.

At the moment V9 of server and 0.3 of the client show that there is
disparity in versions which is understandable for the project not
reaching 1.0.

However, the server's version can change more quickly while the project
is under 1.0, and the major version still have 'free space' to increase
to 0.11 instead of V11 cause there in no difference in having client at
0.11 or 0.3.

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.

Sebastian> One could always write a GUI or cmd line program that will
Sebastian> give the user an option to upgrade , rebootstrap database
Sebastian> versions.

I agree - that should be part of every major release giving ability to
upgrade database format up-to-date.


Sincerely,
Gour


-- 

Gour  | Zagreb, Croatia  | GPG key: C6E7162D
----------------------------------------------------------------

pgpvTnsXa3PeF.pgp
Description: PGP signature