On Sun, Jan 29, 2012 at 03:48:18PM -0500, Bhaskar, K.S wrote:
[KSB] Actually, this is a good segue into another topic, packages and
metapackages. We should have GT.M packages with names like
fis-gtm-5.4-002b and a meta package fis-gtm that depends on
fis-gtm-5.4-002a or fis-gtm-5.4-002b or fis-gtm-5.5-000. Or perhaps
the actual packages will combine a package number with a GT.M release
number, e.g., fis-gtm-5.4-002b.01.
The reason is that once we release a GT.M release, it's frozen for
all time. Thus, might be ICU 4.2, ICU 4.4, etc., which are different
versions of ICU, but each may have a series of releases. But once a
GT.M release or version goes out, there will never be another one
with the same number.
I do not quite understand what's special about that.
Once GNUmed 1.2.0 is released there will NEVER be another
release labelled 1.2.0. The next bug fix release will be
1.2.1 and the next feature release will be 1.3, or whatever
we decide.
There must be something else about GT.M versioning/releases
which I don't quite get yet ?
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