[Maria-developers] CONC/C and CONC/ODBC API and ABI compatibility
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. 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? 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? I assume there is not. If there is, again - why was CONC/ODBC 3.0 discontinued and hidden? -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat --
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
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
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
Hi Michal, about ABI breakage: Since MySQL 4.1 all public structures like MYSQL, MYSQL_FIELD have an opaque pointer called extension, where we add new members if necessary. It will be allocated and populated during runtime. It is considered to be opaque, values from an extension will be retrieved via api functions, e.g. mariadb_get_optionsv(). about version numbers: MariaDB Connector/C has the version format MAJOR.MINOR.PATCH Once we released a MAJOR.MINOR version, we will apply bugfixes only and increase the patch number. If we add new functionality, we will increase the minor version, e.g. after adding the binlog api we released 3.1 after 3.0 If we have a lot of significant changes we bump the major version: E.g. in 3.0 we added a new plugin concept, support for various tls libraries, bulk processing for prepared statements, better unicode support etc. Usually you don't need to recompile applications when uograding from 3.0 to 3.1. Hope this helps /Georg
Yes, that is exactly what I was looking for.
Thanks!
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Mon, Jul 8, 2019 at 3:14 PM Georg Richter
Hi Michal,
about ABI breakage:
Since MySQL 4.1 all public structures like MYSQL, MYSQL_FIELD have an opaque pointer called extension, where we add new members if necessary. It will be allocated and populated during runtime. It is considered to be opaque, values from an extension will be retrieved via api functions, e.g. mariadb_get_optionsv().
about version numbers: MariaDB Connector/C has the version format MAJOR.MINOR.PATCH
Once we released a MAJOR.MINOR version, we will apply bugfixes only and increase the patch number. If we add new functionality, we will increase the minor version, e.g. after adding the binlog api we released 3.1 after 3.0 If we have a lot of significant changes we bump the major version: E.g. in 3.0 we added a new plugin concept, support for various tls libraries, bulk processing for prepared statements, better unicode support etc.
Usually you don't need to recompile applications when uograding from 3.0 to 3.1.
Hope this helps
/Georg
participants (3)
-
Georg Richter -
Lawrin Novitsky -
Michal Schorm