[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/2.6.27.29-0.1-default; 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.
http://wiki.gnumed.de/bin/view/Gnumed
http://wiki.gnumed.de/bin/view/Gnumed/InstallerGuideHomeShort
http://wiki.gnumed.de/bin/view/Gnumed/ReleaseStatus
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
http://packages.debian.org/squeeze/gnumed-client under suggests.
And if you still want to find a way to break things you certainly will.
Sebastian
- [Gnumed-devel] Choice of programming language and project management (Was: Phillip Eby of Python), Andreas Tille, 2009/09/05
- Re: [Gnumed-devel] Re: Choice of programming language and project management, Karsten Hilbert, 2009/09/06
- [Gnumed-devel] Naming convention (Was: Choice of programming language and project management), Andreas Tille, 2009/09/07
- Re: [Gnumed-devel] Naming convention (Was: Choice of programming language and project management), Jim Busser, 2009/09/07
- Re: [Gnumed-devel] Naming convention (Was: Choice of programming language and project management), Karsten Hilbert, 2009/09/07
- Re: [Gnumed-devel] Naming convention (Was: Choice of programming language and project management), Jim Busser, 2009/09/07
- Re: [Gnumed-devel] Naming convention (Was: Choice of programming language and project management), Karsten Hilbert, 2009/09/07
- Re: [Gnumed-devel] Naming convention (Was: Choice of programming language and project management), Jim Busser, 2009/09/07