Symphony.

Symphony’s recent 2.0.7 release has called attention to some flaws and inefficiencies in our current development and release procedures. We understand that the community relies on us for a stable, reliable product, and we’re committed to getting these issues sorted out quickly as we move forward. Among the changes you can expect to see are the following:

More Careful Source Code Management

Since Symphony’s code base was first moved to Git, the integration branch has been pulling double-duty, accommodating both minor bug fixes and more fundamental changes in the core code. For this reason, our official policy has always been to caution the community against using the integration branch since we couldn’t vouch for its stability. Unfortunately, this has also meant that the code on the integration branch wasn’t being very thoroughly tested before being merged into the master branch, and that sometimes changes were introduced that could cause breakage.

Moving forward, our plan is to add a third branch to the repository, allowing us to protect the stable and testing branches from changes that are not backwards-compatible. With a stable release branch, a bug fixing and testing branch, and a branch for experimental code, you will be able to develop, test, and upgrade with more confidence.

Scheduled Release Cycles

We’re exploring the possibility of moving to a scheduled release cycle—probably every 8 or 10 weeks for minor point releases. This will, we hope, establish a development rhythm that will encourage more routine testing. Also, it will help us ensure that minor point releases are just that—minor—reducing the chance that the sheer magnitude of changes in a release will create compatibility problems.

Release Candidates

Two weeks prior to any minor point release, and 4-8 weeks prior to any major point release, we’ll lock down the testing branch against any further additions, and ask developers and volunteers to put the code through its paces by upgrading and testing non-production Symphony projects.

Development Timeline

Moving to a scheduled release cycle will enable us to maintain a development timeline here on the website. Though not a full-fledged roadmap, the timeline would key the community into testing periods and give some indication of the broad trajectory of Symphony development.

Clearer Development Direction

We need to do a much better job of communicating ongoing development goals and providing clear direction for community-fueled efforts such as localization and translation, coding conventions, etc. In addition to simply being more responsive on the forum, this will likely involve a new category here on the blog where we can regularly address issues related to Symphony’s development direction.

We’ve got other ideas too, and would love to hear yours. As we set about implementing these (and other) improvements, we’ll be listening to your feedback and keeping you up-to-date with our progress. We hope these and other changes in the coming year will help make Symphony an even more stable product and development platform for all of you.