"What's in a name? That which we call a rose by any other name would smell as sweet." Romeo and Juliet (II, ii, 1-2)
Sometimes a name is everything. It can convey meaning and emotion. In the world of software, a name can convey the stability or instability of a release. The name, or label, that we apply to a release is our way of communicating to you some important information about our product.
Next week, for the first time since DotNetNuke was created, we will be releasing a Community Technology Preview (CTP). This CTP will be for the upcoming DotNetNuke 6.0 release. Later this spring we will release another CTP, a Beta or two and a Release Candidate (RC).
Each of these terms (CTP, Beta, RC) represents a specific milestone in our release process and it is important to understand the distinction to know what you can expect in each release. Most developers in the Microsoft ecosystem will understand the terminology, but this post is intended to be a refresher so that as we discuss these releases in our community everyone will know what we are talking about. Our definitions may be slightly different than the way it is used by other companies and that is ok, as long as we are consistent in our usage.
So what do we mean when we use these terms?
Community Technology Preview (CTP)
In the DotNetNuke vernacular, a CTP is an opportunity for customers to get an early look at a particular software feature. While other upcoming features may be included in the CTP, our goal is really about identifying issues with just a couple of specific features which we will outline when we release the CTP. In general we are looking to the community to answer a few key questions: Does it work the way people expect? Is the feature useful? Have we missed some obvious or not so obvious bugs? We expect the software to be stable but not necessarily release quality. The goal is to support all primary use cases – create portals, add pages, add modules, add users and set permissions. Because the software is still undergoing development, we know that there will be some parts of the release which are a little buggy or where a feature is not fully implemented. That is ok and is to be expected.
A CTP is a great way for the community to get an early look at where we are headed with a release. Because of the timing involved and the types of questions we expect to get during a CTP, we will only do a CTP during one of our major releases. These releases have more substantial feature enhancements and architectural changes and CTPs will provide a valuable opportunity for the community to see what we are working on and to give us feedback in plenty of time to be able to change the feature as necessary.
As software is developed it goes through several stages in terms of feature implementation and software quality. At some point in the development process, a company may release a version of its software for testing by their user community. Historically companies have released Beta versions of their software where the beta release represents software with a certain quality level (quality is relative to the company – the beta release for some companies may have higher or lower quality than a beta from another software vendor). DotNetNuke often provides Beta releases for our maintenance and major releases.
A beta release is a mostly completed release. At this point in our release process we will have implemented most of the major features planned for a specific release. We might still have some cosmetic changes or usability enhancements left to finish, but we don’t anticipate adding any major new features once we have reached the Beta phase. Like CTPs, we know that there are still bugs and minor enhancements that the team may be working on. The product has not gone through our full suite of test cases but it should install and all of the primary use cases should be functioning correctly. This is another great opportunity for the community to provide feedback on the stability and quality of the release. At this point there is still some time for significant bugs to be fixed.
As anyone who has been in the community knows, we have frequently used Betas for both major releases as well as for our maintenance releases. With major releases, we might have multiple betas, since these releases are larger in scope and are likely to have more issues found during testing that need to be addressed. Our maintenance releases tend to be much more tightly scheduled and may only have a single beta.
Release Candidate (RC)
By the time we hit a Release Candidate, the product is pretty much frozen. We have gone through all the major test scenarios and are just running through a final set of regression tests and verifying the packaging. In the absence of any major show-stopping bugs, this is the product which will be released. At this point we only have a week or two until the anticipated release date and are really just taking one last look before we release the product. Any issue found at this stage will likely just be logged in Gemini and be scheduled for correction in a follow on maintenance release.
What am I running?
When reporting issues or making enhancement requests in Gemini, it is important that you properly identify the version of the software you are running. During CTPs (labeled as Alpha in the window title) and Betas, you will be able to see the exact version you are running by looking at the Title bar in your web browser as shown below (click to expand the image). This version information is removed during a production build in order to avoid leaking information to your site visitors.
Regardless of the build you can also go to the Host Settings screen to see the current version number (you won’t be able to distinguish an alpha, beta or RC release though).
One thing to keep in mind with all of these releases – these are only provided for testing purposes and should not be run in production environments. These builds have not gone through all of our testing and may have significant problems which may not manifest immediately in your environment. These builds are also not guaranteed to be upgradable to a final release build. For these reasons and more we suggest you run these builds in a controlled test environment.
In 2011 we expect our community testing efforts to become more consistent and provide a greater opportunity for community involvement in our release process. We look forward to your participation in this effort.