On 02/08/2014 09:13 AM (US Eastern Time), Karsten Hilbert wrote:
On Sat, Feb 08, 2014 at 08:17:52AM -0500, Bhaskar, K.S wrote:We do not distinguish between releases and versions in GT.M. While most packages have versions and releases of versions, there is only one version of GT.M with a series of releases. Bugs are only fixed in new releases. Once a release is out, it's frozen for all time. So, while most packages are trees, GT.M is a line.While, yes, terminology needs clarification that's exactly the point -- it needs clarification *because* its meaning is arbitrary. In more general terms (regardless of what any project chooses for themselves) a "version" is a defined state of the code declared to *be* a version (it could be a tag in a VCS). A release is a version having been "packaged and made available" for non-dev consumption. And that's that. Minor, major, main, branch, line, bug fix release, maintenance release, feature release, you name it. All the same. If I understand this policy correctly, users of GT.M don't have a chance of installing a bug fix into their system by way of a "bug fix release" ? They can "only" either manually install a fix (by, say, an intra-vista package installation ?) or by means of upgrading to that version of GT.M and/or Vista which does contain the fix -- which may mean they'll get a whole new version with perhaps lots of features none of which they want/need ? Assuming the upgrade procedues of GT.M/Vista work extremely reliable this may even be good for Debian since no one will ever be clamoring for Debian uploading a bug fix release for a Debian package that only ever lived in snapshots.d.o or some such ...
[KSB2] Although GT.M made it into Debian via Debian Med because GT.M is a FOSS platform for VistA, GT.M is separate from VistA. GT.M is an application development and technology platform that is widely used in banking and healthcare, as well as in other applications (if you want to interact over the Internet with a GT.M application not in either banking or healthcare, try the library catalog at http://lib.ua.ac.be). I speak for GT.M but not for VistA, although I have some knowledge of VistA.
The core of GT.M is built and released monolithically, and the only choice for GT.M users who want a bug fix is to use a new release. Yes, a new release may have new features that they don't want or need, but users usually upgrade because they don't worry about regressions. It is very rare for us to create a regression by design, it is usually something like a required new flag on a command line for a utility program. And while we do have regressions that are bugs, they too are very rare because when we fix a bug or make an enhancement, in parallel with the software change, we also enhance the automated regression test suite. Then, both the source code change and the automated regression test suite change go into version control and become a permanent part of the GT.M development infrastructure. So, the only real regressions are to application code that relies on the presence of a bug, or that relies on a certain limit of GT.M. So yes, GT.M users do upgrade without having much concerns (of course we always advise them to test first).
VistA is different. VistA is very patchable. If you install version x of VistA, you will always be able to get to version y by applying a series of patches.
Regards -- Bhaskar
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.