> > Also I'm afraid that if we have a lot of different features in the > progress that will create a crazy possible combination matrix. How to > ensure everything behave correctly with all the others, or only some of > them inside the community version? >
In the same way projects handle different versions of libraries, through requires and conflicts declarations. > So I don't understand why we need the php-community version if it contains > "only preinstalled" extensions that users can experiment themselves. Maybe > it can allow verifying adoption but that means users that will switch to > the community version for a daily usage and it'll split the user base. > > However I think deeper features and experiments are important. I think > that extension can't completely change PHP behavior today, extensions might > only have access to specific part of the engine lifecycle. Maybe it can be > interesting to add more hooks so extensions can leverage deeper features > and changes? > > I think it can simplify this RFC by having a complete separation between > the engine, stable and production ready and the experiments (which can stay > extensions). > > With PIE it's now easier to install extensions and also test them. > > > This way users can install extensions, tests features. An extension become > really useful it can still be merged in the core like it was done in the > past (maintainers can still maintain the core part). > The point is not to setup scaffolding in PHP for feature extensions. The point is to bundle experimental extensions into PHP (even normal PHP), in order to speed up adoption across the entire ecosystem, including shared hosts. > > > > >
