delta/ruby-gems/chef.git/lib/chef/server_api_versions.rb, branch https

Fix protocol negotiation for unversioned objects

2020-07-28T21:07:57+00:00

We generally always do protocol negotiation on the get of the node
object and the Chef::Node is an unversioned API, so we need to
test that we backoff the API version to the highest version the server
offers and then retry again.

Signed-off-by: Lamont Granquist

Remove copyright dates

2020-04-13T22:47:17+00:00

Legally incredibly dubious, particularly since we don't follow it
strictly as policy, and we have git history instead, which does it right.
This is just a waste of time and a cargo cult.

Signed-off-by: Lamont Granquist

This hits the ones that are most frequently required.

2019-05-21T01:05:36+00:00

Stops the kernel from scanning through all the activated gems every time in order
to resolve names into pathnames.

See rubygems/rubygems#2762

Signed-off-by: Lamont Granquist

Have a sensible default for old chef servers

2017-07-05T11:20:35+00:00

If we don't see a version header, we should default to only supporting
API version 0, and if we can't support that, then we should die as usual

Signed-off-by: Thom May

Allow the best API version to be queried

2017-03-28T10:32:00+00:00

Also tidy up in the face of the real world.

Signed-off-by: Thom May

Make it easier to have a versioned factory

2017-02-14T19:45:44+00:00

classes providing an API should include VersionedAPI, whilst the factory
class includes VersionedAPIFactory.

Signed-off-by: Thom May

Beginning of automatic API version detection

2017-02-14T18:22:23+00:00

When we make a request to a chef server, we capture the minimum and
maximum support API versions and allow them to be queried.
We then provide some infrastructure for making decisions on which class
should be used, in a middleware-ish mechanism.

Signed-off-by: Thom May