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]

Hi Joel,

Thank you for the prompt and positive response. It's greatly appreciated.

Taking over the docker-php organisation would indeed be a significant step forward. I believe it could offer more continuity for existing users, as they'd see updates and improvements directly on the original codebase. This would be beneficial in fostering trust and avoiding confusion.

However, before making any final decisions, I would like to consult with @flavioheleno and ensure everyone is on the same page. We want to ensure a smooth transition and unified direction as we move forward.

Again, thank you for your openness to these changes and your kind words. The PHP community has benefitted immensely from your foundational work, and we're excited to continue building on it.

cc: @flavioheleno, @rodrigoaguilera

[flavioheleno]

Hey, nice to hear back from you Joel.

I'm fine with taking over docker-php, we just need to figure out how to put our changes/releases in a way that won't get anything broken or confuse users.

[rodrigoaguilera]

Hi Joel and the docker-php bunch
I think the ideal scenario is to take over the docker-php namespace, at least is way better than the current scenario with the abandoned project and the fork.

Since beluga-php/docker-php and beluga-php/docker-php-api are full forks I don't see much trouble with the migration.

One proposal for a smooth transition is to push the master branch of beluga-php/docker-php as the main branch of docker-php/docker-php and release a major version 3.0.0 there so nobody can get it by mistake unless the use a kamikaze constraint like docker-php/docker-php: "*" in their composer.json.

Can we ensure there is access to the github org and packagist for the namespace and that can be transferred?