Version 2.0

[dvdheiden]

We're currently looking to improve this client. The cluster API is approaching the state where no or a very limited amount of breaking changes will be made. That will make it easier to maintain and to provide a better and more stable package for all the users of the Cluster API client (including myself). That's the reason I want to start thinking about a version 2 of this package.

Requests

One of the things we can improve on, in my opinion, is making it more clear with data is required to perform a certain action. I.e., which fields should be provided for creating a UNIX user.

Currently, the model is used for everything, for creating, updating or retrieving data. I would like to switch to using the specific request classes, in which you MUST provide the required data and CAN provide the optional data. So when I look at the UNIX user create flow, you would build the UNIXUserCreateRequest which can only be built when all required data is provided. Then the create method receives the request: cluster()->create($unixUserCreateRequest). When working like this, you can only have valid states.

This solves #7

Models

When the UNIX User of this example is retrieved, the model with all the data is returned.

PHP 8.1

As PHP 8.0 is almost EOL, I intend to drop the support for PHP 8.0, which means you need to have at least PHP 8.1.

Enums

With bumping PHP to 8.1, we also gain access to proper enums. As the cluster API uses quite a few enums, this would also benefit the idea of always having valid states.

Your ideas

As I'm just one of the users of the package (and the maintainer), I would love to hear from you about your ideas or what you think we should improve for this package.

To be sure, the scope is this package itself, the cluster API is out of this scope.

[dvdheiden]

I intend to start the development soon.

Please let me know if there are any ideas/requirements/wishes for this package, so I can figure out if I can incorporate those in the next version.

[mbardelmeijer]

From our side: we generally don't have issues with V1 other than the nullable fields stuff as noted above. One general note would be that having some kind of way the package can follow the cluster API versions automatically for new fields on existing resources (i.e. not having a allowlist of fields, but allow the end-user to specify which columns to send), would be something welcome to have. Not sure how that would work with validation etc, but just an idea.

[WilliamDEdwards]

As PHP 8.0 is almost EOL, I intend to drop the support for PHP 8.0, which means you need to have at least PHP 8.1.

Done in #116

[WilliamDEdwards]

Updated + summarised in #117