Difference between swoole and swoole-nyholm
Radiergummi opened this issue · 5 comments
It would be nice were the difference between the two runtimes documented; I'm unsure which runtime to select, or whether they are production-ready (the version number doesn't indicate so).
Could you clarify the documentation a little?
If you are creating an application build on top of PSR 7 the swoole-nyholm package is the correct one as that is the one working with psr middlewares and https://github.com/php-runtime/swoole-nyholm#psr and will install the nyholm/psr7 package to provide that support.
If you are in a symfony application which returning the Kernel in your index.php you can use the https://github.com/php-runtime/swoole#symfony. Same for laravel applications.
If you creating pure php application based on swoole request response classes you can use the swoole: https://github.com/php-runtime/swoole#pure-php.
So it depends on the framework you want to use which package you need to install.
Why overall the packages still are 0.x there are not many changes for swoole or roadrunner. As they are not a lot of rocket science here and I would consider them as stable. On other side on runtimes like bref there is still a lot of changes as you can see in the history.
Thank you, that cleared things up. Concerning the version numbers; I tend to treat pre-1.0 releases with caution, as the API might change. Is there any particular reason why the version number of the stable runtimes isn't incremented past 1.0 yet? (Not trying to be mean-spirited but honestly curious.)
We should not forget about the project target:
It is not "the source of all runtimes", but rather a temporary place where runtimes can live before they move in to Bref/Swoole/RoadRunner etc.
So if all goes right the runtime will be official supported by there organisation and will live there. I still would say the packages should be released as a group as 1.0 to be sure that all work together like expected. Still think people have a false feeling about 0.x packages. There are packages which release every half year a new major release and there are packages which were on 0.x for years like phpffmpeg and php imagine, which were more stable libraries then any frameworks around them. I never understand the no 0.x package policy in some companies. Still this is my personally opinion and doesn't represent maybe the main maintainers opinion on this topic.
Fair enough, that is reasonable and I'm thankful for all the effort as-is.
That being said, I know there are stable 0.x packages, but I don't like having to worry about things breaking in production because some vendor wasn't as responsible with backwards-compatibility as you or eg. the phpffmpeg developers are.
0.x indicates changes may happen at new release. >1.x indicates changes should not happen; that gives a soft guarantee that I can update to a new patch or minor release without monitoring the change logs too closely.
SemVersion like composer usage is handling ^0.1 -> ^0.2 the same way as ^1.0 -> ^2.0. So also when you are not using a composer.lock file you are not getting accidently a newer version with breaking changes. And this library is following semver and will not add breaking changes to a patch release. So you are about bc breaks same safe as when we would already be on 1.0.