On 01/29/2012 05:48 PM, Karsten Hilbert wrote:
On Sun, Jan 29, 2012 at 04:50:56PM -0500, Bhaskar, K.S wrote:
Also, users routinely have multiple GT.M
releases or versions installed on their computers, and multiple GT.M
releases peacefully co-exist on the same computer.
Like PostgreSQL 8.4/9.0/9.1 and GNUmed 0.7, 0.9, and 1.1 ?
Surely there must be a way to
- release a bug fix version
[KSB] Bugs are only fixed in new versions/releases.
I am not sure I quite understand what you are saying. There
will, of course, be a new version number and a proper
release when "recompiled" code is packaged up even if the
one and only change is in fixing one character in one line
of one file (a bug, that is). That would seem standard Good
Practice to me (not that everyone follows that, though). I
do not foresee any problems from that regarding Debian
packges. How would this release approach influence packaging
fis-gtm?
[KSB] I think the only interaction is that we would expect a Debian major
release to use (say) libicu44 and not switch to libicu46 (or libicu48)
till the next major release. And there is a series of updates to
libicu44. With GT.M, it will be reasonable and customary to have
fis-gtm-5.4-002a, fis-gtm-5.4-002b and fis-gtm-5.5-000 to all be
available for the same Debian release.
This is not incompatible with Debian package management. I was only
point out that it is different from many other packages in that regard.
- enable a user to "transfer" her data/configuration
to 5.5-000 who initially ran 5.3-017g-whatnot
[KSB] We are very particular about regressions. So, it's usually
just a matter of recompiling the code, and if a database upgrade is
required, running the database upgrade. On those rare occasions when
we must make something not 100% upward compatible (and it is indeed
very rare), we flag it in the release notes.
I agree what you describe here is Best Practice (as done in,
say, GNUmed as well).
So, when I install fis-gtm 5.3-017g today and next week
Debian delivers a package containing the code for 5.5-000
will there be a way for me to upgrade my database/M code ?
If so, then I fail to see the problem with Debian providing
the new GT.M version to me via a package ? And later
providing me with a 5.6-002z package allowing me to run,
say,
/sbin/fis-gtm-upgrade
[KSB] Yes, that's the general idea. But it's a little more complicated
than that because, for example, you may want to build new shared
libraries for the code, and occasionally other configuration files may
need to be tweaked or extended.
Regards
-- Bhaskar
?
Thanks,
Karsten
--
GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
