gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Re: versioning scheme


From: James Busser
Subject: Re: [Gnumed-devel] Re: versioning scheme
Date: Wed, 24 Sep 2008 14:40:15 -0700

On 24-Sep-08, at 10:26 AM, Gour wrote:

"Karsten" == Karsten Hilbert <address@hidden> writes:

Karsten> It does not "have to". It rather "can not" for the reasons
Karsten> Sebastian detailed".

I agree: it does not have to, but I fail to understand why it can't...

I have not worked things through far enough to know that some middle ground is unachievable, although maybe others already realize why.

So far, a change in database always requires the release of an updated client.

Changes in client code (bug fixes or new functionality) may or may not await a change to the database. If a new functionality depends on a change in database, the implementation and therefore release of this functionality will depend on (and will have to await) the release of the new database.

It is understandable that versioning of software which depends on "other software" is unlinked in terms of its numbering scheme, when the softwares are of two different origins by two or more different groups but it is understandable that some synchronization might be hoped-for inside a single project.

The one other factor is the ease with which the developers can *easily/efficiently* adapt and adopt a new approach. I agree that every change risks to be more work and that there is always the question of short term pain as long as there will be longer term gain.

In this case I am wondering if (within the database) there is the possibility of patching or bug repair that may not actually need a new client, if this would require an xx.xx approach for the database.

In theory an alternate db numbering system could see the next _v release to be

_v00033

and db patches could be

_v00033a, _v00033b

Next, suppose the client can added enough new functionality where it was desired to "jump it" to 0.4.0 my questions would be:

1. is it realistically possible that this could happen without a change in the db version? It seems to me that we are contemplating at least little enhancements to the db all the time and so it may always be possible to release an at-least-slightly new version of the db as _v00040? If it is the user-facing functionality which determines the "meaningfulness" of version numbering, do we care and must we be upset if there never existed a db _v00034? We do not seem bothered by the fact that we skip client version numbers.

2. is there a concern about the orderliness and reliability of the bootstrap code when it needs to enforce upgrades based on the parsing of version numbers? It is already suspected that we could have hit a bug as the bootstrap tried to go from _v9 to v_10 and so if we were to go from _v00033a to _v00033b I can understand that this would make any iterative loops more complicated, and all the more if there would be skipping to _v00040 since the bootstrapper may not know and may have to be told (making it more error-prone) what it is allowed to skip.

3. is there a concern that forcing people into too many db changes including trivial ones is something truly important to avoid? I do see this stage of interruption in a production system to be one that would make me nervous... the bootstrapper would upgrade the database and I would need to be checking that the new client (with its config modified to the new db) would have to be tested since even if everyone else would tell me it works ok it may be my responsibility for my praxis to agree. Then in the meantime the actual data which has continued in the existing pre-upgrade db has been changed so we need to then schedule brief downtime to get the old data into the new db and deploy all the new clients and make sure to revoke the old ones so that people do not continue to connect and alter data to the old db and now we are all on the new db which contained only a trivial change. If we are possibly releasing at least a minor client upgrade every month or so do we really want production systems to have to upgrade their dbs this often in order to enjoy the benefits of the new client when no change to the db had been required?

It seems to me that #1 as a reason to want to sync the versioning is at least matched in the opposite direction by #2 (user frustration against work/complexity for developers) but that when we add #3 I see the weight in favor of going against Gour's proposal even despite that it has some merit... I think it is just outweighed by the competing arguments.




reply via email to

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