[Top][All Lists]
[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
----------------------------------------------------------------
pgpUpRitn_mAQ.pgp
Description: PGP signature
Re: [Gnumed-devel] versioning scheme, Sebastian Hilbert, 2008/09/24
Re: [Gnumed-devel] versioning scheme, Karsten Hilbert, 2008/09/24