Allow Celery class to connect to different broker and backend

[jdufresne]

Constructor accepts two connection arrays.

Flattens class hierarchy. Remove CeleryAbstract and CeleryAdvanced. Now
Celery is full featured. Remove hierarchy as it provided no additional
useful abstraction or reuse.

[gjedeer]

This looks like an API breaking change and the project promised not to break any APIs. Please don't merge any changes that don't pass the unit tests.

[gjedeer]

https://github.com/gjedeer/celery-php/blob/master/DEVELOPMENT.md

[jdufresne]

Unit tests do pass, see the Travis CI status. I bumped the semantic version to handle the change in API.

[jdufresne]

Additionally, the change significantly cleans up the organization of the code and makes the base class more flexible in the general case. I think you should reconsider.

[gjedeer]

Yeah, you changed the tests so of course they pass. The reason why they exist is to ensure API stability. I won't stop you from merging that but it breaks the primary goal of this project. There was a reason why a second constructor was introduced instead of changing the Celery class, it was not a choice based on ignorance but on a promise given to the users.

…

On 3 May 2017 18:27:39 CEST, Jon Dufresne ***@***.***> wrote: Unit tests do pass, see the Travis CI status. I bumped the semantic version to handle the change in API. -- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: #104 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[jdufresne]

I understand your point of view.

In a previous commit, I've changed the major version to signal to library users that there will be some API changes. I've also included a CHANGELOG.md file with strong wording where APIs have been altered. I too want the users to know about these changes, but I don't want them to hold the library back.

My goal with the API changes is to bring celery-php up to modern PHP standards and clean API practices. I don't plan to do the next release until I'm confident all potential API changes are in, so it only occurs once. In addition, I hope to have a look at rebasing and merging the Celery4 v2 protocol changes so this library can live on with improved, long term Celery support.

I plan to continue supporting celery-php after all the changes land. So if there is strong feedback I'll be around to fix and help.