Release version 0.2.0

[busbey]

I'd like to get 0.2.0 out the door by the end of June. Normally, I'd want to set some goals for things to include in a release, but this one is kind of simpler

• everything that's gone in the last ~3 years
• verified working guide for running on windows
• verification that at least 3 of the bindings work

I expect this first go will be bumpy. To meet the end-of-June goal, I plan to cut a release branch off of master starting June 15th (barring special circumstances).

[busbey]

If folks could volunteer for testing particular data store bindings that would be a super big help. To make the release notes the testing will have to be on one of the release candidates, but seeing if things work at all right now (and filling in missing READMEs) would be grand.

[busbey]

I think #250 and #261 will have to be blockers.

[busbey]

we need a manual check that #91 behaves correctly.

[busbey]

My kid was ill over the weekend, so I didn't get to finish #250. Presuming no one has a strong objection, I'm going to punt the release branch to Wednesday Jun 17th.

[busbey]

All of the blocker and critical issues for 0.2.0 are solved now, so shortly I'll create the release candidate branch and post up what kind of testing I'd like to see here.

[busbey]

release branch blocked on #306

[busbey]

Here's my plan for driving the release:

1. Branch 0.2.0 (0.2.0-staging) and tag version 0.2.0-RC1 (source only)
2. Testers should build and use either the distribution artifact (ycsb-0.2.0-RC1.tar.gz) or a binding specific distribution (e.g. ycsb-hbase-0.2.0-RC1.tar.gz)
3. Testers should file issues/prs for problems found
4. Fixes for issues should go to master. I'll pull things back to the release staging branch. if you are feeling generous feel free to cherry-pick bug fixes back, but no new functionality please (adding a README.md so that a datastore gets its own distribution tarball is fine)
5. When issues come up, I'll start cutting new release candidates every other day off of the 0.2.0-staging branch.
6. When the final release is published, I'll delete the branch. The tag from the release will remain as a starting point if we need to make a patch release.

Successful testing of a datastore binding should be noted here. please include:

• datastore binding (e.g. hbase)
• version of datastore tested against (e.g. hbase 1.0.0 cluster)
• if the datastore has different single node / clustered modes, which was used (e.g. hbase standalone)
• OS for client
• packaging used (either the distribution artifact or a datastore specific artifact)
• workload used
• other options used

Things we need to get through for a release:

• release notes (which I'll build as we test things)
• running on windows for some datastore binding
• running 3 datastore bindings (other than basic / test ones)
• verification that the different histogram options from Fixing Coordinated omission + replacing histogram with HdrHistogram #214 work
• verification that the export to text / json / json array works
• verification that the data verify from Data Correctness Checking #91 works

The final release will have

• notes
  • compatibility changes for workload / bindings downstream
  • datastore binding changes (new bindings or support for additional version support)
  • measurement changes
  • exporter changes
• source download
• convenience binary distribution artifact
• any datastore binding specific tarball that we've tested

[busbey]

Another thing we need to check: licensing for dependencies that are getting packaged in.

[busbey]

RC1 is available now (ref status page)