New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
4.0 #54
Comments
I'm looking forward to it using with laravel 9. @ksassnowski when do you plan to release? |
There is already a release candidate available that should be stable. I don't expect the actual code to change much until the release so this should be safe to use. In fact, I'm already using it in production. The only thing that's still left is writing a few sections in the documentation. |
Inside the new default
|
Ah, you're right. It should probably be |
Ok! Would you like me to submit a PR? Going through the upgrade as we speak so I'll post here if I find anything else 👍 |
Sounds good. You could maybe also double check if the same is true for the |
class Workflow extends VentureWorkflow
{
public function someMethod()
{
// $this->getState()
}
} |
Ah shoot sorry! I thought I was working off my own fork, but I pushed into Let me know if you'd like this reverted 👍 |
It's fine 👍 |
The development of version 4.0 happens in the 4.x branch of this repository.
Todo
vimeo/psalm
withnunomaduro/larastan
WorkflowStepInterface
for workflow stepsthen
andcatch
callbacks of a workflow (4223133)WorkflowStepInterface
Workflow::define(...)
with$this->define(...)
EntityAwareWorkflows
pluginthen
andcatch
callbacks of a workflowassertStarted
now takes the job's queue connection as a second parameterWorkflowTester
BC Breaks
This section is used to keep track of all BC breaks this version introduces. While I will try to keep them to a minimum and provide sensible migration paths, there are a few warts in the current implementation that require a BC break to really fix.
Drop Laravel 8 support
Starting with 4.0, Venture will require Laravel 9.
Jobs need to implement
WorkflowStepInterface
Since we can't type hint against traits, we currently have to resort to theobject
type whenever we're dealing with workflow jobs. Version 4.0 adds a proper interface and extends the existingWorkflowStep
trait so it automatically implements the interface.Since it's necessary to addimplements WorkflowStepInterface
to all existing workflow job classes, this is a BC break. We should be able to automate this with some sort of artisan command, however (e.g.venture:migrate-jobs
). We basically have to look for classes that use theWorkflowStep
trait and perform some kind of string replace on the class declaration.I found a way to make this backwards compatible for now. Instead, adding a job that doesn't implement the interface to a workflow will trigger a deprecation warning in version 4.
Workflow::define
requires the workflow instance as the first parameterUp until now, the
Workflow
facade'sdefine
method only took a$name
parameter. In version 4, this method takes an instance ofAbstractWorkflow
as a parameter.This is so we can acces the actual workflow class inside plugins, instead of only dealing with the
WorkflowDefinition
class. This allows users to define extra properties/methods on their workflow classes which can then be used by various plugins.As a convenience, the
AbstractWorkflow
class now provides adefine
method which automatically passes the current workflow instance to theWorkflow::define
method.Again, this is something we should be able to automate since it should be a rather straight-forward string replace.
Changes to
WorkflowManagerInterface::startWorkflow
signatureThe
WorkflowManagerInterface::startWorkflow
method now takes a second parameter$connection
which specifies the connection to use for all jobs of the workflow. If$connection
is null, it will use whatever default connection has been set on the job.This is a fairly low-impact change as a I think it's unlikely that people will implement their own workflow manager or extend the default one. It is still a breaking change, however.
StepIdGenerator
needs to account forWorkflowStepAdapter
Jobs that don’t implement
WorkflowStepInterface
directly now get wrapped in aWorkflowStepAdapter
class. This means that when implementing a customStepIdGenerator
, you now need to account for this class and potentially unwrap it before generating the id.The text was updated successfully, but these errors were encountered: