On 17-Aug-08, at 2:37 PM, Rogerio Luz wrote:
It will always be the same database. And if the gnumed_v27
already exists it will be deleted.
So, wouldn´t it make sense to make the devel database use diferent names than the "packaged" versions? Something like gnumed_v9-dev ?
That way it wouldn´t delete nothing and the devel database would never be seen by the "normal" client and bootstrapping procedures?
I can understand the desire for anyone who would run a production backend version of GNUmed to also want to themselves test, and be satisfied what will happen, any new version(s).
I also understand that one codebase managing 2 different installs of the same version of GNUmed on the same system would be asking for trouble.
I also understand how having to rename a backend differently and to have to cascade the changes through all the scripts could be a big headache.
I wonder whether running devel inside a Virtual machine would be the way to safely manage the duality:
- production system runs on server
- doctor hacker installs and maintains a devel version inside a VM on their personal computer
- doctor hacker can get familiar with new backend and client changes inside VM
- VM can be cloned (at no charge if Linux?) to assist other staff to learn the changes
- when satisfied, doctor hacker can load a dump of real data into their VM backend for next stage of testing
- when satisfied, production can be migrated up into new GNUmed
Client updates *within* one version of the database are, I believe, less of a problem. As long as the database has not been upgraded, misbehaviour from a new client version should still allow the doctors and staff to go back to the prior version, is that correct?