Versioning guidelines for product
Download as DOCX, PDF•5 likes•2,945 views
The document outlines guidelines for versioning a product through its development lifecycle stages including alpha, beta, release candidate, RTM, and general availability, with version numbers following the format of PRODUCT (Stage-Number) Major.Minor.Revision to indicate the stage, build number, and changes made. Key stages include alpha for internal testing, beta for external user testing, release candidate when features are complete and only bugs remain, and general availability when the product is broadly released.
Versioning guidelines for product
- 1. Product Versioning GuidelinesHelpful for development and support teams for understanding to versioning scheme Author: Lalit Kalehttp://www.lalitkale.wordpress.com<br />Version Life Cycle for PRODUCT<br />Fig: Versioning Lifecycle for PRODUCT<br />Development and Testing Phase<br />Pre-Alpha<br />Pre-alpha refers to all activities performed during the software project prior to testing. These activities can include requirements analysis, software design, software development and unit testing.<br />Milestone versions include specific sets of functions and are released as soon as the functionality is complete.<br />Alpha<br />The alpha phase of the release life cycle is the first phase to begin Software testing. In this phase, developers generally test the software using white box techniques. It is also known as Private beta. Additional validation is then performed using black box or gray box techniques, by another testing team. Moving to black box testing inside the organization is known as alpha release.<br />Alpha software can be unstable and could cause crashes or data loss.<br />The alpha phase usually ends with a feature freeze, indicating that no more features will be added to the software. At this time, the software is said to be feature complete.<br />Beta<br />\" Beta\" is the software development phase following alpha, named after the Greek letter beta. It generally begins when the software is feature complete. The focus of beta testing is reducing impacts to users, often incorporating usability testing. The process of delivering a beta version to the users is called beta release.<br />The users of a beta version are called beta testers. They are usually customers or prospective customers of the organization that develops the software, willing to test the software for free or for a reduced price.<br />Beta version software is likely to be useful for internal demonstrations and previews to select customers. Some developers refer to this stage as a preview, a prototype, a technical preview (TP) or as an early access.<br />Open (also called as CTP) and closed beta<br />Developers release either a closed beta or an open beta; closed beta versions are released to a select group of individuals for a user test, while open betas are to a larger community group, usually the general public. The testers report any bugs that they found and sometimes minor features they would like to see in the final version.<br />An example of a major public beta test was Microsoft's release of community technology previews (CTPs).<br />Release candidate<br />The term release candidate (RC) refers to a version with potential to be a final product, ready to release unless fatal bugs emerge. In this stage of product stabilization, all product features have been designed, coded and tested through one or more beta cycles with no known showstopper-class bug.<br />Other Greek letters, such as gamma and delta, are sometimes used to indicate versions that are substantially complete, but still undergoing testing, with omega or zenith used to indicate final testing versions that are believed to be bug-free, ready for production.<br />A release is called code complete when the development team agrees that no entirely new source code will be added to this release. There may still be source code changes to fix defects. There may still be changes to documentation and data files, and to the code for test cases or utilities. New code may be added in a future release.<br />Release Phase<br />RTM (Release to Marketing)<br />RTM The term \" release to manufacturing\" or \" release to marketing\" (both abbreviated RTM)—also known as \" going gold\" —is used to indicate that the PRODUCT version has met a defined quality level and is ready for mass distribution either by electronic means or by physical media. The term does not define the delivery mechanism; it only states that the quality is sufficient for mass distribution. The deliverable from the e-Zest is frequently in the form of a gold master CD used for duplication or to produce the image for the web.<br />RTM happens prior to general availability (GA) when the product is released to the public.<br />General availability (GA) <br />GA is the point where all necessary commercialization activities have been completed and the software has been made available to the general market either via the web or physical media.<br />Commercialization activities could include but are not limited to the availability of media worldwide via dispersed distribution centers, marketing collateral is completed and available in as many languages as deemed necessary for the target market, the finishing of security and compliance tests, etc. <br />The time between RTM and GA can be from a week to months in some cases before a generally available release can be declared because of the time needed to complete all commercialization activities required by GA.<br />Another term with a meaning almost identical to GA is FCS, for First Customer Shipment. Some companies (such as Sun Microsystems and Cisco) use FCS to describe a software version that has been shipped for revenue.<br />It is also at this stage that the software is considered to have \" gone live\" . The production, live version is the final version of a particular product. A live release is considered to be very stable and relatively bug-free with a quality suitable for wide distribution and use by end users. In commercial software releases, this version may also be signed (used to allow end-users to verify that code has not been modified since the release). <br />Support Phase<br />Service Pack (SP)<br />During its supported lifetime, software is sometimes subjected to service releases, or service packs. As a well-used example, Microsoft's Windows XP has currently had 3 major Service Packs.<br />Such service releases contain a collection of updates, fixes and/or enhancements, delivered in the form of a single installable package. They may also contain entirely new features.<br />End-of-life<br />When software is no longer sold or supported, the product is said to have reached end-of-life. In this stage all support and maintenance activities for specific version has been closed.<br />Version Naming Guidelines<br />All assemblies (DLL’s) under the product must reflect a single version of product and assemblies. You can achieve this by changing “Assemblyinfo.cs” file under each project under the solution. The smarter way to do this is put a single “Assemblyinfo.cs” under your main project and refer this into other proejects as a “Link File”.
- 2. Version should be released with following naming scheme:PRODUCT NAME (LIFECYCLE STAGE-LIFECYCLE STAGE NUMBER) MAJOR.MINOR.REVISION<br />For example:<br />PRODUCT (Beta-2) 1.2.2345<br />LIFECYCLE STAGE –Lifecycle stages are described in above section of this document. The values can be- alpha, beta, RC, RTM, GA, SP.<br />LIFECYCLE STAGE NUMBER –This is single digit number without “0” as prefix. The range for Lifecycle stage number is from 1 to 5. Even after 5th iteration of lifecycle stage, if the product is not able to achieve quality objectives, then it Lifecycle stage number should not be increased and will be kept under the maximum of its range i.e. 5.<br />MAJOR – This is double digit number without without “0” as prefix till 1 to 9. Major version number is most significant piece of information and will be only increased after significant change in product functionalities.<br />MINOR –This is double digit number without “0” as prefix for 1-9. Minor version number is increased in case of minor changes to existing version of the product and major bug fixes (of type crash, data loss, security).<br />REVISION –This is four digits number. This is revised after each and every internal build that is delivered for testing purposes. One example of fictitious version is shown as per below: Fig: illustration of PRODUCT Version 1.0 through various lifecycle stages<br />