So the Symfony2 RAD Edition one took much longer to get released than anticipated and its not yet exactly where we wanted to be either, as can be seen by the open tickets. At any rate we wanted to stop letting this hang and put it out there. We still have a most of the assigned Liip internal innovation budget left to work on this for this year but we of course also appreciate feedback and assistance from the community. However it will be one of the tricky challenges to figure out exactly how collaboration should work best.
Why bother?
At Liip we do more projects with Symfony2 than any other framework or application platform. While often the entire project consists in the creation of a custom Symfony2 application, we also often do projects using some application platform (fe. Drupal, ckan) and then do the custom development in an integrated Symfony2 application. As such we realized that reducing setup costs for Symfony2 projects will in the long run safe our clients money and let us get to the interesting bits of the project faster. Moreover we noticed that teams tended to get into the same discussions over and over again (fe. XML vs. YAML vs. annotations) etc. While there can be of course arguments about the benefits of either, it seems like for many of these questions we can and should simply define a company standard. This doesn't necessarily preclude things to be different in a specific project but the hurdle is much higher to even bother discussing it. So we decided it makes sense to create a more opinionated version of Symfony2 Standard Edition
Whats there?
Out of the box the RAD Edition right now is still pretty close to the Symfony Standard Edition in many ways. We have added a few extra bundles along with a Vagrant and Capifony setup. There is also a very rough first step towards providing standardized development flows and a DoD but this is by no means yet representative of what we aim for. Furthermore there is a .travis.yml configuration for for Travis CI integration. Furthermore we will collect some meta information in the wiki in order to prevent adding needless text and comments into th project itself that would then need to be removed.
How to play together?
Now the tricky bit with all of this is when we then collaborate with the community we might end up with too many compromises. I mean if specific defaults make sense for us and the entire community, then they should go into the Symfony2 Standard Edition itself. That being said there are of course other web agencies that have a focus on similar projects and have a similar taste. Of course we also have different types of projects and for this we came up with the idea of feature branches with a single commit and an associated open PR as documentation. In the version we are releasing today we have two feature branches: One that can be merged to make things ready for building a REST API and another one that just removes the MIT license. Furthermore we will usually have an example branch for each feature branch that is used to illustrate how to use the given feature. We fully intended to add additional such feature and example branches for things like Sonata Admin, the CMF, BDD etc. The idea is to make it possible to merge these feature branches with as few conflicts as possible at the start of every project. The feature branches also have the side benefit of making it possible to have some functional tests to ensure that the configuration actually works in the real world.
The future
As said in the intro we realize that the current state is not as sophisticated as things need to be in order to serve as a solid basis for the bulk of our Symfony2 projects. We do have allocated an internal budget to improve this and now we just have to find some spare time between client projects to actually make use of the budget. With the release today we hope to however start engaging the community to see who else similar ideas than us to start collaborating.
PS
Special thanks to Alberto from Mayflower, who helped update the Vagrant integration during our recent TechDay event.