RxGRDB backward compatibility v0.11 to v0.12.1 Cocoapods about rxgrdb HOT 5 CLOSED

Hello @KingConnors,

In these versions RxGRDB still has the DatabaseRegionConvertible.swift file which implements the Protocol. But now the GRDB and GRDBCipher versions also contain an implementation of the protocol, which gives a bunch of 'Ambigious' type errors.

Hmm, I see. My tests showed no conflict, but I didn't check your setup.

RxGRDB is still in the 0.x versioning phase, so breaking changes are to be expected. Yet it's not nice when there is no easy workaround 😅

So basically my question is if the dependencies in the cocoapod files for these versions could be set to a specific version of the GRDB or GRDBCipher.

Indeed, RxGRDB before 0.13.0 will conflict with GRDB 3.5. Those versions are sort of dead now.

We could sort of fix this by introducing RxGRDB 0.12.2 with a hard-coded dependency on GRDB 3.4.0. Is this what you had in mind?

from rxgrdb.

We could sort of fix this by introducing RxGRDB 0.12.2 with a hard-coded dependency on GRDB 3.4.0. Is this what you had in mind?

I suppose that would be a nice option. I was considering updating the podspec of the older RxGRDB podspec versions to a hard-coded dependency, since currently they are indeed not working side by side. But having a separate pod version for this could pose as a nice workaround as well, until I (or people like me) can spend the time implementing the latest changes.

from rxgrdb.

I was considering updating the podspec of the older RxGRDB podspec versions to a hard-coded dependency, since currently they are indeed not working side by side.

It looks like it is possible to overwrite an already published pod version. But I'd still have to change tags in the RxGRDB git repository, and this is really not considered a good practice. This would fix one problem by introducing another one.

Don't let me be misunderstood: I'm really sorry about this issue, because like anybody else I really dislike when an upgrade breaks my code.

Did you consider those other workarounds:

1. Don't change your code, but have your Podfile specify explicit versions GRDB 3.4.0 and RxGRDB 0.12.1, so that there is no ambiguity with DatabaseRegionConvertible
2. Have your Podfile specify RxGRDB 0.12.1 and let GRDB bump to 3.5.0, and change your code so that DatabaseRegionConvertible ambiguities are resolved with a prefix, e.g. RxGRDB.DatabaseRegionConvertible.
3. Just use the latest version of both pods. If you have trouble migrating existing observables to ValueObservation, please just ask.

Finally, I'm really happy you are using DatabaseRegionConvertible. It's generally difficult to tell if advanced use cases are actually used by users, and your testimony reassures me on the relevance of this protocol 👍

from rxgrdb.

I am indeed now on a working version again using the latest version of both pods. And I reckon the other two options are fine workarounds as well as opposed to making a separate podspec file.

Thank you for your quick response 👍

from rxgrdb.

Great! All right, I guess we can close the topic now. If other users has the same problem, we'll be able to use this issue as a reference. I hope there won't be too many of them. And I also hope we won't see another breakage like this one until GRDB 4. Thanks for your trust @KingConnors, and happy (Rx)GRDB!

from rxgrdb.