Current coverage is 78.74% (diff: 100%)

Merging #22 into master will increase coverage by 0.49%

@@             master        #22   diff @@
==========================================
  Files             8          8          
  Lines           814        814          
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits            637        641     +4   
+ Misses          177        173     -4   
  Partials          0          0          

Powered by Codecov. Last update cfbaabe...fb77c7c

@minijackson Can this have a test for it please?

Also look at this: https://stackoverflow.com/questions/11887762/compare-version-strings/21065570#21065570

There you go!

But I don't know how to mock the installed tmux to be tmux 1.9a, so while the case that the requested tmux version is "lettered" is tested, the installed tmux case is not.

Travis automatically tests across those tmux versions. https://github.com/tony/libtmux/blob/master/.travis.yml

also you could manually insert the version number for '1.9a'

also you could manually insert the version number for '1.9a'

I didn't understand, is it something I have to do for this PR ? Where should I insert the version number ?

That is fine.

The only thing I'm double checking is how broad support is for pkg_resources. Are there any corner cases where the user may not have setuptools and this patch could lead to a ImportError: No module named 'pkg_resources'.

Even though most machines are going to have setuptools on it, after further consideration it may be safer to use a method without it. I'm not sure what the ramifications would be for upstream packages for tmuxp on arch and slack.

Try LooseVersion instead of StrictVersion.