-
Notifications
You must be signed in to change notification settings - Fork 3
Development and Release Procedures
Symphony needs to continue its transition toward a more dependable, community-driven open source development model. This should improve release quality and help sustain development momentum over time.
The following was proposed during a Symphony working group meeting on 14 April 2011 (transcript). Draft 1 prepared by Craig Zheng on 20 April 2011
Symphony 3 will adopt regular, scheduled release cycles that include established procedures for planning, preparing, and testing releases.
Goals of the new approach will be to release more often and do a better job at managing the scope of each release. Backwards compatibility and ease of upgrades will be prioritized more heavily in the future, even between major releases.
-
Major releases (e.g. 3.0, 4.0)
Yearly. Release cycle lasts one year and begins the day of the previous major release.
-
Minor releases (e.g. 3.1, 3.2)
Quarterly. Release cycle lasts three months and begins on the day of the previous minor release.
-
Maintenance releases (e.g. 3.1.1, 3.1.2)
As necessary. Release cycle length will vary but not to exceed six weeks.
In addition to adopting a regular development cycle, releases will go through more structured procedures for planning and testing:
-
Community Chat
Held at the beginning of a release cycle. This is not an actual planning session but an opportunity to get suggestions and feedback from the wider community
-
WG Planning Session
Held during the first week of the release cycle, to scope and finalize the list of accepted/planned changes.
-
Proposal
Prepared by the core working group and submitted at the end of the first week of the release cycle. 2-3 days for discussion before the plan is finalized.
-
Beta Testing
Probably 4/6 of the way through each cycle, so 8 weeks in for minor releases and 8 months in for major ones. Testing procedures TBD.
-
Release Candidate
Probably 5/6 of the way through each cycle, so 10 weeks in for minor releases and 10 months in for major ones. Testing procedures TBD.
Once the proposal has been finalized for each release, change requests are queued for discussion for the following release (unless they're critical security/stability bugs in which case a maintenance cycle is initiated).