Join GitHub today
Adapter packages #104
In case you noticed: you depend on a lot of "stable" packages that have few dependencies of their own.
This package is a helper package for other tools like SDKs, OAuth clients, ...
How stable is this package?
The problem is, this package is equally unstable as all of your dependencies together. When one of these dependencies gets a new backwards incompatible release, you will need to update your package and publish a new major release in order to provide it. Imagine maintaining that.
What you can do is create a new GitHub organisation, and migrate this package over there. Then start creating new repositories in that organisation, one for every adapter class. Each repository will contain one adapter class and a bunch of peripheral files like composer.json, .gitattributes, ...
Consider creating a base adapter package repository, which you can clone, fill and push up to a new repository.
What depends on what?
The core package depends on nothing. Thus it is extremely stable!
The adapter packages depend on the core package (because that one contains the adapter interface and traits etc). Every adapter package also possibly depends on an external HTTP client, like Guzzle, or Buzz. But the amount of dependencies per package is maximum 2 or 3.
When an adapter is extracted, the core package can suggest using one of the extracted adapter packages using the suggest field in composer.json.
What happens when Buzz releases a new major version?
You can update the buzz adapter package and release a new major version. People who are not using buzz and the buzz adapter package don't have to do anything. People using the old buzz http client can still use the old version of the buzz adapter package. You can even match the version with its external dependency, but I'd advise against it.
What happens when the core package makes a Backwards incompatible change?
All adapter packages as well, because they need to publish a new release which can work with the new version of the core package. If the adapter interface and all of the traits remain backwards compatible, you might be able to get away with new bug releases for all adapter packages which also allow the new major version releases in their composer.json files.
This package is currently at version 0.7.1. By gradually extracting the adapters, you can work towards a 1.0.0. This v1 version will incredibly stable. If you don't have the time to do all the work at once, you could create a 0.8.0 release which has abstracted only one adapter.
I like the idea! I must admit since we were in a pre-release phase I didn't take care of the bullshit it will become when I will release the very first stable version and how I would be able to keep the BC... I would like to finish some work before doing it, so, IMO, I will release the 0.8 version with these updates and then, I will move everything to a new organization in order to follow your proposal!
They can be different, but they don't have to - if this GitHub organization would be to provide (for) a single framework (similar to
I would be very happy to be part of this.
Actually, I am really bad at naming. It could either be something simple, but straightforward, like @jeromegamez's suggestions or something more like a fantasy name. I leave that to you.
(My personal opinion is that
The separation work should not take too much time if it is well planned.
Some ideas that came into my mind:
The cool thing is, Composer supports something like virtual packages. This means that the core package can depend on a non-existing package http-adapter/http-adapter-implementation which can then be provided by the concrete implementations.
You go too fast :)
@sagikazarmark You think your bad at naming but your proposal rocks
I cant' work more tonight, I will move to a party :) I will come back here (probably tomorrow afternoom) and send you invitation to the orga.
Thanks for all your participation!
I created a boilerplate package for adapters:
Will transfer it to the organization.
I think you need to accept the org joining request. I haven't received one,