What do you think about doing a soft migration?
For example, we could support both versions for a while—allowing users to upgrade without changing the interface—while showing a warning that the old version is deprecated.

Once the new version is fully released, we can remove the old logic.

I’m open to it. My initial approach was to expose the endpoint from Http and then surface it through Client. One caveat is that Http gets re-initialized each time the private #http (that's why I'm interested in #77 😁) method is called, though in practice this isn’t a major issue.

Before committing to a soft migration, I’d be interested to know if anyone relies on Http directly, since within the library, only Client seems to use it. If no one else is using Http externally, we can likely proceed without deprecating the old logic. Do you use it?

What do you think?

Before committing to a soft migration, I’d be interested to know if anyone relies on Http directly, since within the library, only Client seems to use it. If no one else is using Http externally, we can likely proceed without deprecating the old logic. Do you use it?

I can’t say for sure whether anyone is using Http directly,
but since it’s part of the public interface,
it’s definitely possible that some users are relying on it or even overriding it.
I've seen quite a few libraries and applications that depend on this package,
so we should be cautious.

I’d recommend taking a soft upgrade path—this way, we avoid introducing breaking changes and give users a chance to adapt, ideally with clear upgrade instructions.

UPDATE: If you think it will be difficult to support, let's update CHANGELOG.md to note that this includes breaking changes in HTTP.

No I don't think it's too difficult 😊 I thought about it and now the endpoint is stored in both classes for the time being!

That's okay with you?

Ping @miry,

can't click re-review for some reason

@treagod Can you add your changes to CHANGELOG?
I run your changes in my projects for some time to make sure it works.