In general: yes. But I think right now we experience more and more instability in Neos and Flow because of refactorings. It adds up, and every change is a wound if you don’t perform the surgery carefully.
Devil’s advocate: which value brings your change to Neos users?
I am not sure if the instabilities can be pinned to the refactorings. Certainly they uncover some broken concepts from time to time and of course any change has a change of breaking something, but lets not go there…
Generally the PackageManager needed osme refactoring but of course we should have solid reasons for this big change, so yes this change has some benefits:
improves performances noticably (you can easily see the improvement with just checking request times in browser) and that is for all contexts
package sorting more robust (you could have a wrong sorting order before)
removes the problem of casing of third party package Flow package keys, because it relies on the composer name which is stable.
Gets rid of complicated Metadata model (hopefully) in favor of directly using composer.json
Allows a (Flow) package to supply multiple namespaces
I took care not to break things too much but that’s why I am putting this up as a project, to get it really nicely done, done.
In my book devs are users too. We didn’t build this rocket science system only for non-devs IMHO.
Uncaught Exception in Flow #1295973082: No class schema found for “TYPO3\Neos\Domain\Model\Domain”.
TYPO3\Flow\Persistence\Doctrine\Mapping\Exception\ClassSchemaNotFoundException thrown in file
/html/neos/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/TYPO3_Flow_Persistence_Doctrine_Mapping_Driver_FlowAnnotationDriver.php in line 123.
Reference code: 201511302337210d9fb3
#1186669086: The action “indexAction” in controller “TYPO3\Neos\Controller\Backend\BackendController” is not public!
TYPO3\Flow\Mvc\Exception\InvalidActionVisibilityException thrown in file
/html/neos/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/TYPO3_Flow_Mvc_Controller_ActionController.php in line 194.
Reference code: 2015113019553722f212
@cgat You should read up about freezing packages. You should only ever do that for packages that do not change. And if they change you need to flush the cache manually, that’s the use of freezing the package. We do no longer need to check for all changes. Generally freezing packages should work though. I will check that myself, but please use another thread for this problem as it is unrelated to the package manager refactoring.
Ok, thanks for your reply. Sorry, I did not make it clearer that I reported because the errors appeard without me (or sombody else) making any changes to packages, nor any other file (happened immediately after pressing “freeze”). I had looked at the bugtracker, but it seemed to require its own manual.
I could reproduce the errors after the recovering as reported by freezing all packages again (even though site breakage did not happen imediately the second time), and a ./flow flow:cache:flush --force actually made the site work again with all packages frozen. So breaking the site instead of just freezing (non effectiveness of changes) seems a instability you may be able to reproduce and fix. (Maybe already fixed or easier with your refactoring. Many thanks, and +1 for your code clean up!).