What is a Community Technology Preview (CTP)?
We've been asked this question quite a few times and have noticed myself that this term is new to many in the PHP community. So we thought we'll take a moment to clarify.
Typically, a software product release consists of the following phases:
- Definition: "what is the release about?", "what are the key themes/scenarios for the release?", etc.
- Planning: "what features align to the definition?", "what is the high-level design for each feature?", "what are the dependencies for each feature?", "how much effort for each feature?", "what is the logical grouping or execution order for the features?", "what are the priorities for each feature?", "what are the release criteria (feature level as well as product level)?", etc.
- Development: "go write the code" – both features and their tests.
- Stabilization: run the tests (feature, integration, end-to-end, stress, performance, etc.), find the bugs, fix the bugs; rinse, lather, repeat.
- Milestone Releases: public release to larger group for feedback on design/bugs.
Many software products use a variation of this process and often have multiple public milestone releases (Alpha, Beta, Release Candidate, Final) with the product quality increasing with each milestone until the release criteria is met. Often, there is a tighter loop with a smaller set of partners to get early feedback while the public releases are for feedback from a larger audience. My previous experience with software used this process and terminology.
The variation within the SQL Server product group is:
- a deeper engagement with the right partners earlier in the planning and stabilization phases to get the requirements, design, and quality right
- grouping the features into multiple "sets" that have a correct logical sequence as well as balance the effort across all the component teams to finish the "set" around the same time
- each "set" is called a Community Technology Preview (some use Customer Technology Preview)
- the release criteria for the CTP are the same as final release (some corner case bugs may be deferred to a later CTP)
There are several benefits that allow teams to:
- move on to the next set of features for the following CTP while our customers/community are able to evaluate the CTP and provide feedback and/or bug reports
- create better plans with more predictable schedules
- eliminate cycles of lower quality alpha/beta releases with higher quality CTP that can even be used in limited production environments and our partners often do (at their discretion since pre-release builds are not supported by Microsoft Customer Support)
- reconsider the design if we have to (often these are just minor tweaks to the existing design)
- improve our test suite based on incoming bugs
Many people outside Microsoft think of a CTP as a "beta" release, we think of a CTP as a "Release Candidate" quality release with the ability to change the design and improve the test suite.
As with any approach, it has its weak spots – one is identifying the right set of partners to get the requirements from and to validate the design. It is evident that our team follows this process since the fist CTP in 2007. We have enjoyed success with it, and we continue to make improvements in mitigating the weak spots (for example, our partner list continues to grow and we really appreciate their participation).
We hope this helps your understanding of our process and terminology, can use our CTP builds with greater confidence, and take the opportunity to provide feedback quickly.
SQL Server Driver for PHP team