Plan for releasing 0.1 version

[ekexium]

We're going to make the project ready for a 0.1 release in the following weeks. Please leave a comment if you have suggestions!

We expect it to be fully functional in most cases, and enable Rust users to freely play with TiKV. Becaues of the publish blocker #32 , we will probably not publish it on crate.io.

Supported functionalities in 0.1:

• Raw API
  • put, get, delete, scan, batch_put, batch_get, batch_delete, batch_scan, delete_range
• Transactional API (optimistic)
  • begin, commit, rollback, put, get, delete, scan, batch_get, lock

Checklist:

• Functionality
  • Whether to remove delete_range delete_range is currently supported by TiKV.
  • GC will not be provided in 0.1 Support GC #180
• Bugfix and test
  • Encoding problem [WIP] Add codec for encoding region for transaction client #162
  • Parameters of group_keys_by_region must be sorted [WIP] Add codec for encoding region for transaction client #162
  • Some requests only sends to the first region because of misuse of stream.into_future Fix some misuse of into_future() #176
  • For end_key, None and Some(empty) should both mean unbounded, while in some palces we miss the second situation. We cannot only use None to represent unbounded because parameters is first converted into kvproto request parameters (which is Vec). Related PR: [WIP] Add codec for encoding region for transaction client #162, Fill a missing situation in bound_range #174, Fix limit problem in raw_scan and unbouned problem in batch_scan #179 . There are probably more.
  • limit only applies to each region for raw_scan and raw_batch_scan Fix limit problem in raw_scan and unbouned problem in batch_scan #179
  • Integration tests
    • raw
    • transactional
• Usability
  • Consistent naming: put/set, key_only/with_key_only, etc.
  • batch_get returns Iter<Option<KvPair>>, while may not contain all non-existent entries. Fix txn.batch_get #173
• Robustness
  • Do not panic when error happens
  • Jepsen Test
• Documentation
  • Tutorial for user Update readme #170
• Examples and use cases

[nrc]

I'm thinking of the 0.1 release again. I think we should aim for the end of March. I've added some issues which I think should be blocking to the 0.1 milestone.

I don't think we need to block on the Jepsen test, though we should probably block a 1.0 on that.

@ekexium are you aware of anywhere where we panic where we should create an error?

[ekexium]

I don't think we need to block on the Jepsen test, though we should probably block a 1.0 on that.

Agree.

are you aware of anywhere where we panic where we should create an error?

I checked it months ago. Recently we've added more functionalities. I'll check it again.

Will we also publish the support of pessimistic transactions and async commit? There is a lack of tests I think.

[nrc]

Will we also publish the support of pessimistic transactions and async commit? There is a lack of tests I think.

Pessimistic transactions yes, async commit no (because we haven't implemented recovery). I think there are enough tests for pessimistic transactions, though I might be wrong. In any case, we don't need to be perfect for a 0.1 launch.

This makes me wonder if we should have a feature flag system for experimental features like async commit, or whether we should just #[doc(hidden)] them.

[nrc]

Everything here is done