gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Re: versioning scheme


From: Gour
Subject: [Gnumed-devel] Re: versioning scheme
Date: Wed, 24 Sep 2008 09:32:17 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

>>>>> "David" == David Mackenzie <address@hidden> writes:

David> For this keep in mind the following: X.Y.Z =
David> Major.Minor.Maintenance/Build

Sure, but since we're not (yet) at 1.0...


David> In my humble opinion, I think that client and server versions are
David> kept separate for a reason and should be completely independent
David> of each other.  Just say a defect fix involved a schema change,
David> the client version should not change its Minor version for a
David> defect fix, it should change its Build No. There are other
David> scenarios like this, but you get the general idea.

I do not agree.

Breaking storage format is of major concern and if we assume that either:

1) end-users have some kind of IT support, then there is no problem for
IT stuff to upgrade BOTH server & the client with the result that the
change is completely transparent for non-savvy end-used or

2) if end-users are installing/maintaining their own setup then it means
they are also capable to upgrade BOTH server and the client, and the
whole thing is not issue at all.

So, it means that for every major release GNUmed can release BOTH server
and the client as one complete tarball, e.g. gnumed-full-0.4.tar.gz or
gnumed-complete.tar.gz, while for minor releases only client's tarball
is released - gnumed-client-0.4.1 etc.

David> Minor version increases should be for new functionality and Major
David> version increases should be for major new functionality.

Right. Take a look in Postgres - the very database GNUmed uses - change
of format is MAJOR one and it requires MAJOR change in versioning.

We cannot argue that "defect fix involved a schema change" is minor if
it changes/breaks storage format and it requires new database format!

This makes things much easier for both maintainers, admins and end-user
'cause the present versioning summarized in

http://wiki.gnumed.de/bin/view/Gnumed/ReleaseStatus 

is total mess - how to logically connect that client-0.3 means databasie
v9 and client-0.2.8 is v8?


Sincerely,
Gour


-- 

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

Attachment: pgpUpRitn_mAQ.pgp
Description: PGP signature


reply via email to

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