Update Carthage dependencies

[ilammy]

• Retarget OpenSSL dependency

Use the upstream repository of OpenSSL instead of my private fork, now that Marcin has merged Carthage support into the mainline.

Currently there is no suitable stable tag so pin a specific commit instead that is known to work.

Update the lock-file as well so that we get correct version after carthage bootstrap.

• Use the latest stable version in examples

EDIT: commit reverted, we'll still pin the version in examples.

Remove version specifiers in Carthage examples which means that we'll always use the latest stable (tagged) version. At the moment this is provisional 0.10.5 version, then it will be 0.11, and so on.

Drop the lock-files as well and add them into .gitignore. That way the users will recreate the lock-files as necessary and won't commit them accidentally during development.

[vixentael]

but cartfile.resolved is used to link to exact lib version, why not to push it?

[vixentael]

@ilammy up

[vixentael]

and you've added these files to .gitignore, but they are pushed below 🤔

[vixentael]

All good except ignoring Carthage files.

Carthage best practices says do not ignore .resolved files:

Along the way, Carthage will have created some build artifacts. The most important of these is the Cartfile.resolved file, which lists the versions that were actually built for each framework. Make sure to commit your Cartfile.resolved, because anyone else using the project will need that file to build the same framework versions.

https://github.com/Carthage/Carthage#for-both-platforms

[ilammy]

@vixentael,

The idea here is to not specify exact version in example Cartfiles so that the examples always use the latest stable version and we don't have to update them manually with every release. If Cartfile.resolved files are committed then the version will be effectively pinned (unless explicitly updated by the user), despite the Cartfile specifying 'the latest' version.

This is done only for examples. Themis itself still keeps the Cartfile.resolved file than pins the exact version of our OpenSSL dependency.

Which way do you prefer? Having the version pinned to examples, or having them automatically use the latest one?

[vixentael]

I think we should leave examples stick to the exact release tag, because in case of backwards compatibility changes, users won't be able to run examples, which is bad.

It's better that we do some job during release to check that examples are working and to update 'em, than users will see not-working examples :)

[ilammy]

Okay then. I have reverted the commit that unpins the versions in examples. They will be updated in a separate PR after this one is merged and we know the commit that we need to pin examples to.

[vixentael]

CircleCI tests are not needed in this case, only Bitrise makes sense.