Deprecate camelCasing

[clintongormley]

Elasticsearch allows all parameters to be passed with underscores or as camelCase (except where somebody has forgotten to handle the camelCase variant, and isn't using parseField #8964).

Also, the keys in responses can be rendered in camel case by passing ?case=camelCase, except that rendering seems inconsistent, eg:

{
   "took": 2,
   "timedOut": false,
   "Shards": {
      "total": 10,
      "successful": 10,
      "failed": 0
   },
   "hits": {
      "total": 1,
      "maxScore": 1,
      "hits": [
         {
            "Index": "t",
            "Type": "t",
            "Id": "1",
            "Score": 1,
            "_source": {
               "foo_bar": "foo bar baz"
            }
         }
      ]
   }
}

Does anybody actually use the camelCase option? Almost all of the documentation uses the underscore version of parameters, and having a single set of accepted parameters (and responses) seems less likely to cause confusion than the current situation.

I'd recommend deprecating camelcase in 2.0 and removing it in 3.0, but labelling this ticket for discussion.

[mikemccand]

+1

[nik9000]

+1

[dakrone]

+1, what about deprecate in 1.5 and remove in 2.0?

[clintongormley]

@dakrone i'd rather give people time to make their adjustments. the use of camelcase in 2.0 would trigger deprecation warnings (see #8963)

[dadoonet]

+1 to deprecate in 1.5 but remove in 2.1 or 3.0.
I'd prefer deprecate sooner instead of later.

[jpountz]

So everyone seems to agree on this issue, the question is more about when the deprecation starts and when we remove. We can only deprecate as of 2.0 because of #8963 and then remove in 2.x. Even though it is a minor release, I would agree with David we should do it sooner rather than later, especially if we have it deprecated from the first 2.0 release?

[uboness]

I don't think #8963 should stop us form deprecating (not having this warning didn't stop us before). Also, I don't think many ppl are using camelCasing or are even aware of it. Also it doesn't feel right removing something like this in between minor versions.

+1 on deprecation for 1.5 and remove on 2.0

[rjernst]

+1 from me as well to deprecate in 1.5 and remove in 2.0.