[Top][All Lists]
[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.