Re: [MoM] Packaging fis-get
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?
> >- 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
?
Thanks,
Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Reply to: