Tests on 2.5, 2.6, 2.7, 2.8 failed.

Since we use small here and in tarantool and some tarantool versions have open symbols aside of the export list (and so symbol name clash is possible, see #59), we can't just promote the small revision here. It'll break tarantool versions (not so old ones), where the symbols are open.

We can accurately backport commits that does not touch data layout of small's structures and don't rework function behaviour much. However I would go into another way.

My plan is to keep small version here for a while: so it will work on all actual versions of tarantool. After some graceful period (a year, maybe) or if we'll see a real customer problem, bump small here and release the new module version (and cleanly state, which tarantool versions are not supported anymore). I would also add a version check and report a good error if the module is run on improper tarantool version.

Anyway, we should confirm the analysis from #59 after PR #102 and understand all consequences of updating the small library in the module.

Or better: fallback to malloc when we can't use small.

Or better: fallback to malloc when we can't use small.

Maybe it is not so good option as looks on the first glance. We'll need to re-implement mempool, region, ibuf and obuf API on top of malloc, which looks as considerable amount of work.

Simmarized possible options in #92 (comment).

In context of the patch: we should at least add the version check in memcached.create() to don't allow to create an instance on tarantool 2.5-2.8. And refrain ourself from releasing the patch until those tarantool versions will gone in the practical sense.