This is intended to start a discussion and exchange on how we can improve the experience for package authors, which was brought up by @robert on github in this issue:
What’s still unsolved is the problem that, through breaking changes we loose compatibility with many user-contributed packages, which makes timely upgrades to new Neos / Flow versions much harder.
I think that this can be improved greatly through tooling – if we provide a good concept for package authors how to maintain multiple branches and give them tools to make code adjustments a no-brainer, we can progress faster with more fundamental changes.
So thanks Robert for bringing this up. I do think we have some way to improve in this regard.
The problem to solve is allowing package authors to support multiple (breaking) major versions of Flow Framework with as little effort as necessary.
This could start with some best practices documentation on how to manage this up to tooling to automatically migrate code.
Right now, our go-to solution is code migrations, but those are not always used and if might not cover all cases. Maybe those need some more documentation on how to create them, or maybe there is some room for improvement in available logic (parse code to AST and replace tokens would be one idea).
So, please add your suggestions and ideas. If you are a package maintainer and are currently dealing with this issue, share your experience - what did you suffer with the most, what did help you? Do you have some process and what does it look like?
What I found hard was to setup and manage all the dev branches for the major package versions. Usually they also correlate somehow to the Flow/Neos versions.
There is also a bit of Git/Composer voodoo there to really get it right.
And then there is simply the effort of maintaining it and testing.
Setting up your own automatic tests for a package is not super straightforward.
Especially because every package out there uses a different CI/CD provider (if they have one). That’s why I try to move to Github actions to have everything at least in one place.
But still one has to find out how to make tests, have them run with different versions etc…
Also having tools in there to keep the PHP code clean.
The setup to run automatic tests on Fusion is also not documented yet as far as I see.
Sadly I experienced several packages where the maintainer only updated the composer.json when a new Neos version comes out and hasn‘t even tested it once
Some simple test that would start up flow via cli would already have helped there.
The only change that caused headaches with some of my packages was the HTTP PSR change in Flow 6. Because it was one of the few without core migrations.
