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

Reply via email to