|
Hi Andreas, We discussed this in the group and a number of people were not comfortable with removing the current versioning scheme. Let me revise my explanation of our versioning: GT.M’s versioning follows this scheme: DBVersion.Major-Minor[Patch] - DBVersion corresponds to the database block version - Major corresponds to a major feature change in the product - Minor represents a minor/incremental feature change in the product - Patch is an alphabet denoting an emergency single change release What do other DB projects do in this case? Could we make the DB version a textual string and ignore it with respect to the version number? Currently V6.3-014 has a FTBFS #1011722 logged against it. It would be good to get V7.0-003 in the testing stream to close the bug. Thanks, Amul From:
Shah, Amul <Amul.Shah@fisglobal.com> 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,
FIS Internal Use Only
FIS Internal Use Only |