Single Core and Subtree Split

This page proposes and outlines the steps necessary to have a single repository with the core Sulu components and bundles whilst maintaining separate packages.

Aim

We should aim to:

• Merge all core Sulu bundles into sulu-cmf/sulu
• Maintain readonly mirrors of the individual packages via the use of git subtree split

Bundles to be merged to core

• SuluAdminBundle
• SuluCategoryBundle
• SuluContactBundle
• SuluContentBundle
• SuluLocationBundle/
• SuluMediaBundle
• SuluSecurityBundle
• SuluTagBundle
• SuluTestBundle
• SuluTranslateBundle
• SuluSearchBundle
• SuluWebsiteBundle

Bundles which will NOT be merged

Question: Should these bundles simply be merged into a sulu-ecommerce package? The bundles could then also be maintained as as independent packages via. subtree splot

• SuluProductBundle
• SuluSalesOrderBundle
• SuluSalesCoreBundle
• SuluSalesInvoiceBundle

To split or not to split (right now)

Should we do the migration and the tree splitting at the same time?

• +: The tests in the existing repositories will continue to work as all dependencies are already installed and there is no need to do a composer install for each bundle.

• +: We can assume that nobody is using any of the bundles standalone and that existing deployments will continue to function using the existing repositories (the next version of sulu-standard will include only sulu/sulu

• -:

Preparation task list

1. Write rewrite script to rewrite the selected repositories into core.
2. Script to migrate issues (? could be done afterwards)
3. Write script to maintain the subtree splits (e.g. use this github hook needs redis and ansible ...
4. Update sulu-cmf/sulu composer file to include replace stuff as with Symfony.
5. Update travis.yml to run the individual bundle tests as with symfony/symfony.

Deployment task list

1. Explicitly backup the existing Sulu repository (ALL history will be rewritten)
2. Run the merge script (on my Laptop) to merge then force push to github
3. Migrate issues to sulu-cmf/sulu
4. Install cronjob to maintain the subtree splits

Benefits and possiblities

The main benefit to this approach are centered around imporved developer efficiency:

1. All sulu packages will share the same version (pros: Makes deployment much easier)
2. Refactoring is much easier
3. Testing other peoples code is easier

Disadvantages

1. All external bundle dependencies must be declared both in the Bundle and in sulu/sulu

Obstacles

• All depdencies need to be declared in composer.json
  • massive search
  • ... ?
• Update absolute paths:
  • @SecurityBundle:DependencyInjection/Configuration.php - vendor/blah/blah

Migrating PRs / Issues

Migrating PRs presents a challenge which can be overcome in at least 2 ways:

1. Rewriting the history of the PR branch and pulling that branch from sulu/sulu.
2. Copying the changes into sulu/sulu and making a new commit

The second option would be preferable. It would suffice to:

$ cp /path/to/Bundle/SuluFoobarBundle/* /path/to/sulu-cmf/sulu/src/Sulu/Bundle/SuluFoobarBundle/
$ cd /path/to/sulu-cmf/sulu/src/Sulu/Bundle/SuluFoobarBundle
$ git branch my_new_pr
$ git add *
$ git commit -m "My changes"
$ git push origin my_new_pr