Next steps

[flavioheleno]

I'm starting this discussion so we can elaborate what are the next steps that we want/should/could/must take to do some cleanup and improve this library.

IMO, I'd like to add some automation to docker-php-api generation/release based on continuous download of Docker Engine API spec file.

I think it's also important to review the test suite to ensure it adheres to the whatever version we decide will be supported.

Which leads to the third point, what version(s) should be officially supported and for how long should support be maintained.

Looking forward to your inputs @Rid & @rodrigoaguilera.

• docker-php-api automation
• test suite review
• what version(s) should be supported
• how long should each version be supported

[rodrigoaguilera]

Just wanted to appear here briefly to thank Flavio for taking the project forward and I hope I can bring some value to it.
I don't have a lot of bandwidth now to look deeply into the next steps but two things pop out of my brain:

• The current strategy of supporting the last 3 versions of the docker engine API seems quite reasonable. I would add a notice trigger_error('Deprecated', E_USER_DEPRECATED); if you use the oldest of the three.
• I wish for a single-package docker-php so the docker engine version can be chosen at run-time instead of at composer-require-time. Or at least a mono-repo to handle things more centrally.

[Rid]

Thanks for starting this discussion to plan out the next steps for improving the library. I appreciate your insights and agree with many of your points. Here are my thoughts on each:

• docker-php-api automation: While I see the benefit of automating the API based on continuous download of the Docker Engine API spec file, as far as I know, the spec doesn't get updated very often. So, if implementing this requires significant engineering effort, it may not be worth it at this time.
• Test Suite Review: Absolutely agree on this. The test suite is crucial for ensuring the reliability of the library. Currently, I'm having to do manual testing, which is far from ideal. Focusing on this would probably be the most impactful next step.
• Supported Versions: I'm in favor of supporting the last 3 versions of the Docker API. It strikes a good balance between offering compatibility and manageable maintenance.
• Mono-repo: I'm open to this idea but would like to hear more about the specific use-case it would serve. If it's technically feasible and beneficial, I have no objections.

As for the overall status of the project, I believe we have a stable version now. I'm actually about to deploy the latest version into production, which is a testament to its reliability.

Additionally, I'd like to suggest that we formally split the fork from docker-php/docker-php upstream. I don't see any compelling reason to keep tracking it. Following on from that, it might be a good idea to ping @joelwurtz to see if we can become the recommended replacement package for docker-php/docker-php on Packagist, and perhaps update the readme to direct people to this fork.

Looking forward to hearing your thoughts and those of the community.

[flavioheleno]

I appreciate your efforts on helping maintaining the library, it's great to have people around to discuss and share the work 😄

So, if implementing this requires significant engineering effort, it may not be worth it at this time.

It should not be too much effort, I can tackle that once I get better of my current 🤧 which is keeping me low on available energy.

I'd like to suggest that we formally split the fork from docker-php/docker-php upstream.

Agreed. Maybe we should rename the packages to beluga-php/beluga-php & beluga-php/beluga-php-api to further differentiate it from the original fork?

Following on from that, it might be a good idea to ping @joelwurtz to see if we can become the recommended replacement package for docker-php/docker-php on Packagist, and perhaps update the readme to direct people to this fork.

I'm all in for that as well.

[Rid]

Agreed. Maybe we should rename the packages to beluga-php/beluga-php & beluga-php/beluga-php-api to further differentiate it from the original fork?

I think from the name it wouldn't be immediately clear that the library involves docker, I'm not completely against it though as I can't really come up with anything myself.

@joelwurtz doesn't appear to be on X/twitter or mastodon, I think perhaps the best way of communicating with him would be opening an issue in one of his repos?

[flavioheleno]

We may find him at jwurtz@jolicode.com

[Rid]

Thanks, I've just emailed him.

[joelwurtz]

Hey sorry didn't see those notifications,

i will respond here instead of the email for transparency: i don't have a problem for linking to your repository into packagist and docker-php repo.

There may be also the possibility for you to take over the docker-php organisation (need to check if i have full right on this) i don't mind, but will do what you prefer if you want to stick to beluga-php.

I'm glad there is still interest into having a docker PHP client thanks a lot for continuing this work.

[Rid]

Hey @joelwurtz

Please can you get back to us on this. Work is continuing on our fork, but the original docker-php is still the most visible.

Thanks!

[joelwurtz]

It should be good, i invited you to the repository (you should have the rights) and also make this package as a remplacement of docker-php/docker-php in the meantime

[Rid]

Thanks @joelwurtz, that's much appreciated. I've also invited @flavioheleno.

@joelwurtz do you mind also adding me to the packagist packages? That way we can push our updated changes and continue releasing there. We've addressed all of the issues we had previously with Jane, so we're clear to generate packages up to the latest docker engine API version.

[joelwurtz]

done sorry for the wait

[Rid]

No problem @joelwurtz thanks for doing that, just one last request before I can publish new packages, would you mind adding me to https://packagist.org/packages/docker-php/docker-php-api ?