Given folks can lock to a previous release, is deprecation necessary?

See #166 (comment):

I would love to drop support for python2.6, but this would affect many downstream dependencies that use jmespath. If we're going to do this, we'd need to have a deprecation period first to give people a heads up.

I'm pretty sure that it would not, since folks downstream with well-designed requirements files / setup.py / whatever they use to express dependencies will have already locked their builds to a specific major or major.minor of jmespath which would keep them compatible with python 2.6 until they can move forward.

Codecov Report

Merging #175 into develop will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           develop    #175      +/-   ##
==========================================
+ Coverage    98.19%   98.2%   +<.01%     
==========================================
  Files           14      14              
  Lines         1441    1446       +5     
==========================================
+ Hits          1415    1420       +5     
  Misses          26      26

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0d5762b...a5c9b22. Read the comment docs.

Updated to resolve conflicts!

I'd suggest moving forward with this process, as you can see Python 2.6 and 3.3 are not available on Travis CI:

$ curl -sSf -o python-2.6.tar.bz2 ${archive_url}
curl: (22) The requested URL returned error: 404 Not Found
Unable to download 2.6 archive. The archive may not exist. Please consider a different version.

$ curl -sSf -o python-3.3.tar.bz2 ${archive_url}
curl: (22) The requested URL returned error: 404 Not Found
Unable to download 3.3 archive. The archive may not exist. Please consider a different version.

https://travis-ci.org/jmespath/jmespath.py/builds/569774974

Also, Python 3.4 is also now EOL and no longer receiving security updates (or any updates) from the core Python team.

I suggest deprecating/removing that as well.

Wow, Python 2.6 has reached its EOL in October, 2013. More then six years ago! I hope that all folks who uses it are already well prepared. I think that it (at least 2.6) can be dropped even without deprecation warning.

I know it's been a while, but I want to follow up on this. Here's my plan.

I think it's fine to move fairly quickly on deprecating 2.6/3.3, especially given some of the largest downstream dependencies have dropped 2.6/3.3 recently. Initially I was surprised at the large number of 2.6 downloads, but in looking into it more, it seems to closely match the 2.6 numbers of the aws-cli/botocore which has already dropped 26/33 support.

| category | percent | downloads  |
|----------|--------:|-----------:|
| 2.7      |  51.87% | 22,981,642 |
| 3.7      |  16.73% |  7,411,660 |
| 3.6      |  13.75% |  6,092,117 |
| 2.6      |   6.98% |  3,090,928 |
| 3.5      |   5.05% |  2,237,316 |
| 3.8      |   3.34% |  1,481,817 |
| 3.4      |   1.77% |    785,991 |
| null     |   0.50% |    222,783 |
| 3.9      |   0.00% |        482 |
| 3.3      |   0.00% |        222 |
| 3.2      |   0.00% |          4 |
| Total    |         | 44,304,962 |

Date range: 2020-01-01 - 2020-01-31

So here's my plan:

• I'm going to get a 0.9.5 release out that adds support for py38
• I've created (Update travis to pass on all supported python versions #194) that fixes travis for 2.6. I'll merge that and then rebase this PR with those changes.
• I'll cut 0.10.0 that officially deprecates 2.6/3.3.
• The next version, 0.11.0, will remove support for 2.6/3.3. I'll give this about a month, so I'll plan on a release March 30th.

Let me know if there's any questions/concerns.

Merged via #195