|
Hi Andreas, Thanks for changing the subject and dropping the bug tracker. I realized my faux pas after the bug tracker replied to my email. > > Could you remind me about what we are doing to cause this problem? Is it the installation path? > > Or did you mean the below situation where there are two possible GT.M versions? > > > aptitude search fis-gtm > > p fis-gtm - metapackage for the latest version of FIS-GT.M database > > i fis-gtm-6.3-002 - package for FIS-GT.M database > > p fis-gtm-6.3-014 - package for FIS-GT.M database > > We (rather you, Bashkar and Luis Ibanez) decided to create a new binary > package name for any mikro fis-gtm release to enable co-installation of > all those packages. I'm personally not convinced, that any single minor > version bump needs to be installed on a typical Debian installation. > This I would rather go with binary package names like fis-gtm-6.3 or
> fis-gtm-7.0 no matter whether what mikro version "-002" currently - may
> be "-003" next etc. the package is featuring.
[amul] I think we’re on the same page, to use MAJOR.MINOR in the package name. Neither Bhaskar nor Luis Ibanez are working on fis-gtm. Let me discuss this here at FIS. I don’t see any reason why we cannot adopt the naming scheme that you propose, fis-gtm-Major.Minor, which also matches what other projects use. > However, I do not know anything about fis-gtm and its compatibility between > micro versions - so may be I'm just on the wrong track while looking from > a Debian packaging perspective. My perspective is that I'm just scared > by uploading to the new queue for every single micro version bump which > always is causing unpredictable delays until the package gets accepted in [amul] GT.M’s versioning follows this scheme: Major.Minor-Increment[Patch] - Major corresponds to the database block version - Minor corresponds to a major feature change in the product - Increment (micro) represents a minor feature change in the product - Patch is an alphabet denoting an emergency single change release [amul] GT.M database formats (major version) change infrequently. Inside a database version, GT.M is tested in various upgrade<->downgrade scenarios. Meaning that there should be no reason to not upgrade. Thanks, Amul From:
Andreas Tille <andreas@an3as.eu> Hi Amul, |