[Top][All Lists]

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

Re: [Gnumed-devel] Re: Choice of programming language and project manage

From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] Re: Choice of programming language and project management
Date: Sat, 5 Sep 2009 19:44:57 +0200
User-agent: KMail/1.12.0 (Linux/; KDE/4.3.0; i686; ; )

Am Samstag 05 September 2009 18:07:57 schrieb Jim Busser:
> On 5-Sep-09, at 1:09 AM, Gour wrote:
> > Some points:
> >
> > a) tarball is named GNUmed-server.v11.0.tgz using not so common *.tgz
> > suffix (tar.gz is more standard one) and why is there v11.0 in the
> > name
> > instead of more standard GNUmed-server-11.0.tar.gz?
I see no particular reason why this cannot be changed.
We have said continously that the server version is entirely independent from 
the client version. As the server stabilized there will be less server 
releases then client releases. It makes absolutely no sense to increase the 
server version with every client release.

What makes sense it to point users at the tgz which inlcudes the tgz for 
client and server. 

> While I am not responsible for the choice, tgz and tar.gz are
> equivalent, .tgz is shorter. In my view within any one project, it
> makes sense to stay consistent i.e. one or the other. But I see no
> reason when a project has already taken one approach to change it. To
> me it is equivalent to a complaint whether a project is documented in
> Oxford English or American English. I don;t think this is a sizeable
> (sizable) issue.
> > b) name of the package is not consistent with the content, i.e. when
> > one
> > opens the tarball there is no GNUmed-server.v11.0 folder, but
> > GNUmed-v11.0 :-(
This is indeed something that should be changed and I believe can be 
incorporated in future versions.

> I know there was prior discussion on this. I cannot speak for everyone
> but I remain open to consider things (which we do not even
> *immediately* need to change) if the benefits would be eventually
> decided to outweigh the downsides. Any solution does need to *not*
> cause problems. Therefore if for example the use of decimal versions
> names would (in postgres) cause any problems then we would have an
> argument for the database version to be incremented in whole numbers.
We do already. we have database 10.5 for client 0.4.5 and we will have 11.11 
for client 0.5.11

I don't get all the fuzz. Client and server are installed only a few times in 
many years when in production.

As long as one installs the correct client / server pair noone will care. It 
is don only once or twice. If you manage to screw it up the client will tell 
you right when you try to login.

This discussion is of category 'nice to have' but does not and I repeat does 
not bring in a single user or developer.

Pairs are listed in the Wiki.

I mean if you try to be the network admin or advanced 'I can install all that 
myself' user you really should look at the documentation

And if you are still lazy the client will tell you. And if you don't count 
that as an argument the packages manager will try to prevent you from screwing 
up as per under suggests.

And if you still want to find a way to break things you certainly will.


reply via email to

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