5.0 incompatible changes plan

[cben]

• CHANGELOG for all the new merged stuff since 4.x.

• changed under_score algorithm make api_service method work #355

• document watch Document watch and upcoming changes #436

• change watch exceptions behavior document that watcher stops see #273 and add each_with_retry #275 (comment)

• support ruby 3.0 Ruby 3.0 Compatibility #500

• drop EOL ruby versions ≤2.4

• I'm thinking about making all methods not documented in README private?

  • Specifically get_entities, patch_entity etc?
    These are used in the wild a bit. Should I keep them until alternative Expose {create,delete,...}_entity methods to manipulate objects of dynamic kind #332? But .public_send("get_#{...}", ...) while clumsy is workable, .send and a major release is perfect time to make people aware they're using undocumented functionality.
  • .rest_client too. UPDATE: replaced by .faraday_client, intentionally public.
    • TODO document
  • header manipulation hacks like samson did for Support for apply command #358 ?

  I don't want these to hold up 5.0, or block people from migrating.
  OTOH, private methods are still available with .send(...), just people will be more aware it's unsupported.

• several tests disabled due to expired TLS certs test TLS certs expired #483

• truffleruby failing on master with "ArgumentError: unknown keyword: status"
  e.g. https://github.com/abonas/kubeclient/pull/495/checks?check_run_id=2044157037
  UPDATE: now passes e.g. https://github.com/abonas/kubeclient/runs/2535621628 🤷‍♂️

[cben]

• What about Remove deprecated KubeException [WIP] Remove deprecated KubeException #293?
  => Not now. As explained there, HttpError is not sufficient, we need some top-level exception. Should probably introduce a Kubeclient::Error but that's a compatible change, and should give users time to adopt it before dropping KubeException.

[cben]

Apologies for delays. Working from home with kids has been... challenging.
I hope to get a lot done next week.

[grosser]

I'd propose:

• get rid of most of the api:
  User has to set the api version and resource anyway, so much more efficient and simple to call client.get("nodes") without doing the extra api discovery 🤷
• remove struct and return hashes ... it's an expensive crutch :D

[cben]

get rid of most of the api

That will be an entirely different gem 😄
There is a non-breaking road though: first implement #332, then much later see how well people adopted new style and how people feel about dropping existing API.

remove struct and return hashes

Now that it's simple matter of ``as: :parsed/as: :parsed_symbolized`, I don't see a large enough payoff to justify breaking compatibility.
We could do small nudges like make `as:` required in `Client` contructor to stop encouraging a bad choice. Or even make people require and inject recursive-open-struct and stop depending on it?
But forcing people with lots of working `.foo.bar` code to rewrite everything to `[:foo][:bar]` form would be a disservice IMHO.

If you care about this, start by changing README to prominently explain why the new modes are recommended.

In short, both of these points sound more "8.0" (and maybe never) then "5.0" to me :)

[cben]

• .rest_client is definitely going private (or away) to unblock Replace rest_client with faraday #466.

[grosser]

#332 sounds like a good step forward ... requiring `as` also sounds good (with or without removing struct runtime dependency)

…

On Tue, Nov 3, 2020 at 9:48 AM Beni Cherniavsky-Paskin < ***@***.***> wrote: - .rest_client is definitely going private (or away) to unblock #466 <#466>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#435 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACYZY35UYNXZRLEGUQSNDSOA665ANCNFSM4LFBW3GA> .