**Topics to discuss / Possible topics** [Benni] - How to have composer and installed extensions deal with "PackageStates.php" at best? => We have the situation that we don't have a database connection at install time. We need a CLI-based installer first before we can even tackle this problem. => Next steps: Evaluate how symfony does that, check if TYPO3 could provide such a thing as well. - How should we deal with "uninstalled" / "installed" extensions in the future? => Will be kept for now, PackageStates.php only holds an array of installed extension keys. - How could we deal with extensions that could be put into the composer vendor directory? Is this feasible? * - How should we treat assets then? * - Puli, see \url{http://puli.io/} * - \url{http://insight.helhum.io/post/102899003500/delivering-a-more-secure-frontend-with-typo3-cms} - soutHow to get composer + extension manager closer?sout - Should we follow a subtree split approach soon (for v8) of the main TYPO3 Core repository? => we need github.com/TYPO3/ repositories for each system extension (Helmut and Benni can help) => \url{https://github.com/dflydev/git-subsplit} => \url{https://github.com/neos/slicer} => Only for 8LTS/ master as we still have hard dependencies on extension locations * => put entry point scripts in packages * => add a "typo3/typo3" package with minimum/full dependencies * => decouple extension paths to enable system extensions in different locations * [Mathias] sout- Can we drop PackageStates.php? (E.g. automatically have all Composer packages with type "typo3-(cms-)extension" available?) sout * -(Sascha E.) How would you disable core extensions like workspaces?) * => No changes, remove from PackageStates.php * *- soutDeprecate "typo3/cms" and have developers require the necessary parts? (Optionally add a "typo3/typo3" package with minimum/full dependencies.)sout*- Exclude tests from dist archives (via .gitattributes "export-ignore") [Alex] * Can we get rid of ext\_emconf.php? * Requirements to do so: * EM must be able to parse composer version constraints * Can be done with new EM, that fully relies on composer * EM/ PackageManager must know about typo3-ter/ packages * typo3-ter packages will disappear after 8 LTS as composer.typo3.org will die * What about sections in ext\_emconf.php which do not have a counter part in composer.json? * soutWe need a "title" field and Mathias will contact composer developers to include it in schemasout * Has been rejected when proposed once: \url{https://github.com/composer/composer/issues/1140} * What about old TER then? * Can TER be replaced with a fork/enhancement of packagist? (not the service but the software – \url{https://github.com/composer/packagist)} * Packagist itself will be used for the package management, TER will be a frontend with extra information for each package. * Drop T3X format if yes? * Yes [Helmut] * How should we deliver Extensions in the future (TER 3.0?) * Packagist only * Fix loose ends in composer.typo3.org especially review potential security impact * Create a small standalone lib to parse ext\_emconf.php reliably and securely and start using that in typo3 composer installers * Add proper blacklist for classloading (Tests, ...) for typo3-ter/ packages * Remove typo3 install code from composer/installers (pull request) and check if conflict works properly * TYPO3 6.2 : drop composer.json parsing in PackageManager? * Fix current TER Server with new and outdated sections in ext\_emconf.php * Fix composer installer to write correct ext\_emconf.php * create an official t3x packer/unpacker library to have this code centralized * * composer.json validation tool * ext\_emconf.php validation tool "AlwaysOn" Extensions Activate / deactivate Extensions by installing them with a Composer symlink (helhum) Make system extensions independent from the core, only install needed Extensions Database updates during Extension install => We have the situation that we don't have a database connection at install time. We need a CLI-based installer first before we can even tackle this problem. => Next steps: Evaluate how symfony does that, check if TYPO3 could provide such a thing as well. Problem: loading order of Extensions can not be determined => check if composer.lock is sorted by dependencies => far furture: if Puli packages are used the loading order might not be relevant any more No removal of Package states in the short term Subtree Split Not for version 7 because of too many dependencies We need to move all files that are not within a system extension => index.php => sysext/frontend => cli\_dispatch.phpsh=> systext/backend Remove hard dependencies and exension paths (allow system extensions in typo3conf/ext) Tools => \url{https://github.com/dflydev/git-subsplit} => \url{https://github.com/neos/slicer} Create a minimal base package typo3/typo3