Thank you Lawrin for the replies, > Should be always safe with ODBC. Glad to hear that.
> With C/C everything is possible, and that is basically why 2.3 is still > maintained. I understand, that the difference between 2.3 and 3.x may be significant. All of my questions however were about the differences inside the same major version "3", so I meant "3.0" vs "3.1". I still would love to get the answers from the CONC/C project mainatiner(s) or developer(s). I guess the right person would be Georg Richter, based on the JIRA "assignee" field on CONC/C tasks. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Jul 4, 2019 at 8:03 PM Lawrin Novitsky <lawrin.novit...@mariadb.com> wrote: > > Hi, > > Hello, > > 25.06.2019 15:52, Michal Schorm пише: > > Hello, > > > > I am a Fedora packager and I'd like to make myself sure on some > > assumptions I made. > > Just to make sure in the following conversation: > > * I understand "Connector C 3.1.2" as "major version number . minor > > version number . release number (or sometimes refered as patch > > number)". > > * In Fedora we use dynamic libraries and dynamic linking whenever > > possible. We are building the CONC/ODBC on top of CONC/C. > > > > > > 1) ABI & API compatibility > > I assume, the major versions are fully API & ABI (backward) > > compatible. That means to me it is safe to upgrade to later versions > > of the same major version number when using end-user application. > > There's no need to rebuild the end-user app. > > > > "The MariaDB Connector/ODBC 3.1 series is built on top of MariaDB > > Connector/C 3.x" > > That means to me I can build the CONC/ODBC 3.1 on top of CONC/C 3.0 > > and there's no need for rebuild, when I upgrade to the CONC/C 3.1. > > Thus it is safe to upgrade withing one major version without any threat. > > Exactly. > > Btw, first C/ODBC releases used 3.0 only because C/C 3.1 wasn't GA to > the moment. The next 3.1 release will already be using. > > > That means to me I can update the package in Fedora mid release. > > During a lifetime of a Fedora release (let's say Fedora 30), I only > > update packages which won't break ABI & API compatibility. If there > > would be potential risk, I would push that update only to the next > > Fedora release (developement branch - Fedora Rawhide). That's what I > > do e.g. with minor versions of MariaDB server. I won't update the 10.3 > > to 10.4 in the lifetime of one release, but prepare the 10.4 to the > > next release. (Fedora Rawhide) > > > > Am I right with above assumptions? Can I safely upgrade within one > > major version of the C and ODBC connectors and don't need rebuild of > > the dependant packages and end-user apps? > > If not, why was CONC/ODBC 3.0 discontinued and hidden? > > Should be always safe with ODBC. With C/C everything is possible, and > that is basically why 2.3 is still maintained. > > But 3.0 is discontinues since we believe 3.1 is complete and safe > replacement for it. > > > 2) Version upgrade > > Is there any reason to use other than latest GA release of those connectors? > > (e.g. to use CONC/C 3.0 series instead of 3.1 series) > > Perhaps when using against different MariaDB server major versions? > > No. And again - that is why 3.0 is discontinued. > > > I assume there is not. > > If there is, again - why was CONC/ODBC 3.0 discontinued and hidden? > > Looks like all your assumptions were correct. > > Best regards, > > Lawrin > > > -- > > > > Michal Schorm > > Software Engineer > > Core Services - Databases Team > > Red Hat > > > > -- > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~maria-developers > > Post to : maria-developers@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~maria-developers > > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
