Release IRealitio as a Separate Package

[0xferit]

It would be nice to have IRealitio as a separate package and with different versions for different solc minor versions.

Currently, I'm creating a contract that needs to use IRealitio but I need it in solc 0.7.x. And I have to duplicate IRealitio in my repository for this reason, unfortunately.

[edmundedgar]

OK, looking into this. I wonder if it's possible to make the interfaces work across all reasonable versions?

[0xferit]

Probably not guaranteed across minor versions of Solidity, because of breaking changes. But a package for the interface could have release branches for different solc versions.

For example, release a package with version 4.x.x for solc 0.4.x and release a package with version 5.x.x for solc 0.5.x and so on.

[edmundedgar]

Makes sense, are there any projects I should look at that you'd consider "best practice" for this?

[0xferit]

No, but this explains shortly: https://www.gitkraken.com/learn/git/git-flow

Basically the idea is to create release branches for different solc minor versions. Git flow is suitable for this.

[edmundedgar]

Just working on this as I reorganize everything around a monorepo and fix the branding to hose out Realitio stuff and standardize it all on reality.eth.

I think what we'll end up with is a layout like
contracts/interfaces/solc-0.4.25/IRealityETH.sol
contracts/interfaces/solc-0.7.whatever/IRealityETH.sol
...and something similar for the ABIs.

I don't think we'll bother with separate versions for all of these, we'll just make the ABIs inclusive so if version 1 as function1() and version 2 replaces that with function2() we'll just stuff them both in the ABI and the interface, and make a compatible version for any solc version somebody wants to develop with.

I think that's simpler than running separate branches for everything.

We'll have contracts/flat/RealityETH-2.0.sol to store the actual source the thing was compiled with, but the ABI and interface definitions will be designed to work with whatever the user wants to use, regardless of what they were originally deployed with.

Would that solve your problem?

[0xferit]

I think what you describe is a practical way for a maintainer, indeed, but it's not so nice for 3rd parties to see everything in one file and confusing what's needed and what's not. So this seems like a trade-off between making life easy to maintainer vs integrators. However, integrators' life can be made easier also by good documentation, clarifying all these.

About my problem; I don't have a problem anymore actually because I already understand all the details now and even created my own subset of Reality interface which has only necessary parts of the original interface, so you can consider this 'issue' just as a suggestion to make life easier for future integrators.