vadirajks/Alpha vs Beta Apps and Nightly vs Production Builds

## Alpha vs Beta Apps and Nightly vs Production Builds
https://instabug.com/blog/alpha-vs-beta-apps/
https://stackoverflow.com/questions/46786486/alpha-beta-snapshot-release-nightly-milestone-release-candidaterc-whe

RC = Release candidate; probably feature complete and should be pretty stable - problems should be relatively rare and minor, but worth reporting to try to get them fixed for release.
GA = General availability (a release); should be very stable and feature complete

++++++++++++++++++++++++++++++++++

Alpha:
The alpha phase of the release life cycle is the first phase to begin software testing (alpha is the first letter of the Greek alphabet, used as the number 1). In this phase, developers generally test the software using white-box techniques. 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
Alpha software can be unstable and could cause crashes or data loss. Alpha software may not contain all of the features that are planned for the final version. In general, external availability of alpha software is uncommon in proprietary software, while open source software often has publicly available alpha versions. 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.

Beta
"Beta Test" redirects here. For the film, see Beta Test (film). Beta, named after the second letter of the Greek alphabet, is the software development phase following alpha. Software in the beta stage is also known as betaware. Beta phase generally begins when the software is feature complete but likely to contain a number of known or unknown bugs. Software in the beta phase will generally have many more bugs in it than completed software, as well as speed/performance issues and may still cause crashes or data loss. 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 and this is typically the first time that the software is available outside of the organization that developed it. Beta version software is often useful for demonstrations and previews within an organization and to prospective customers. Some developers refer to this stage as a preview, preview release, prototype, technical preview / technology preview (TP), or early access. Some software is kept in perpetual beta, where new features and functionality are continually added to the software without establishing a firm "final" release.
Beta testers are people who actively report issues of beta software. They are usually customers or representatives of prospective customers of the organization that develops the software. Beta testers tend to volunteer their services free of charge but often receive versions of the product they test, discounts on the release version, or other incentives.
As the Internet has facilitated rapid and inexpensive distribution of software, companies have begun to take a looser approach to use of the word "beta". In February 2005, ZDNet published an article about the recent phenomenon of a beta version often staying for years and being used as if it were in production level, disparagingly called "perpetual beta". It noted that Gmail and Google News, for example, had been in beta for a long period of time and were not expected to drop the beta status despite the fact that they were widely used; however, Google News did leave beta in January 2006, followed by Google Apps, including Gmail, in July 2009. This technique may allow a developer to delay offering full support and responsibility for remaining issues. In the context of Web 2.0, people even talk of perpetual betas to signify that some software is meant to stay in beta state. Also, "beta" is sometimes used to indicate something more like a release candidate, or as a form of time-limited demo, or marketing technique. Since the introduction of Windows 8, Microsoft has no longer been naming their software as a beta. Instead, they have been using the term preview for most pre-release software. Since the launch of the Windows Insider Program back in 2014, all pre-release builds that are released through the program are known as Insider Preview builds.

Snapshot and Release:
A snapshot version in Maven is one that has not been released.
The idea is that before a 1.0 release (or any other release) is done, there exists a 1.0-SNAPSHOT. That version is what might become 1.0. It's basically "1.0 under development". This might be close to a real 1.0 release, or pretty far (right after the 0.9 release, for example).
The difference between a "real" version and a snapshot version is that snapshots might get updates. That means that downloading 1.0-SNAPSHOT today might give a different file than downloading it yesterday or tomorrow.
Usually, snapshot dependencies should only exist during development and no released version (i.e. no non-snapshot) should have a dependency on a snapshot version.

Nightly:
A nightly build is a neutral build that takes place automatically. These typically take place when no one is likely to be working in the office so that there are no changes to the source code during the build.
Nightly builds are a good thing, they provide immediate feedback to developers if they broke the build. Having a nightly build means that the software stable and is likely to build for new users. Software that is not built regularly is difficult to release.

Milestone:
Milestone versions include specific sets of functions and are released as soon as the functionality is complete.

Release Candidate [RC]:
Release candidate. A release candidate (RC), also known as "going silver", is a beta version with potential to be a final product, which is ready to release unless significant bugs emerge.
Release Candidate (RC) is the build released internally to check if any critical problems have gone undetected into the code during the previous development period. Release candidates are NOT for production deployment, but they are for testing purposes only.

+++++++++++++++++++++++++++++++++++

Alpha Build:
The first alpha build is the first working version of your app, which doesn’t always have the full features implemented. It is often too buggy to be usable, but contains, at a minimum, the core functions of the app ready for testing.
Developers will add any missing features and, along with QC, focus on finding, tracking, and squashing as many bugs as they can find. When the app becomes “feature complete” and no major crashes or bugs remain, the alpha phase is considered complete and the final build then becomes the first beta version.
Traditionally, you would conduct alpha tests internally without involving anyone outside the development cycle, however, using external testers or even end-users for the alpha phase is not unheard of. In fact, it has recently become relatively more popular among smaller development teams that don’t have a dedicated QC team.

Beta Build:
The beta build is the version marking the completion of the app’s development. Traditionally at this stage, no new features are added and focus becomes on improving the quality, usability, and overall experience. Beta is the first build available to users outside development and can still suffer from bugs and stability issues. However, it should not have any major issues and is considered a full-featured, usable version.
Beta testing programs can either be closed with access restricted to invited members or open where anyone can participate. Either way, the app is tested in “real world” environments with “real world” scenarios by external testers/users. Due to the greater diversity of device environments and use patterns, this helps uncover many bugs that slipped through earlier test phases. The developers will then use the submitted bug and crash reports to pinpoint and fix all the reported defects and iterate on the builds until the application is ready for release.
Since beta testing is the first time users get to try the app, it is the first opportunity for validation. Currently, most beta builds utilize tools to allow in-app communication, in-app surveys, track in-app behavior, and automate bug and crash reporting to maximize the feedback they receive about functionality, usability, and feature requests. If feedback uncovers major flaws in features or functionality, the team will address them before release; otherwise, the feedback is implemented in the next iteration.

Nightly Build:
Honoring the principle of “integrate early, integrate often”, as the name suggests, the nightly build changes every night. It is an automated build that is made at the end of the day by incorporating all the changes made during that day. They are not restricted to any stage of the development lifecycle and are used throughout the cycle, i.e. during alpha/beta testing (or any other stage of development). A nightly build is produced every day reflecting any changes to the code.
Nightly builds are typically not accessible to anyone outside the development lifecycle but are sometimes shared with select external testers. They are on “the bleeding edge” of development and can be buggy and unstable. A nightly build towards the end of a beta cycle should be stable while one at the beginning of the alpha test is not usable.

Production Build:
When you iterate enough on the beta build to be stable and no new bugs or feedback is being received, QA will mark it as a “release candidate” (also called “going silver”). At this point, developers will not make any changes to the app except for minor code fixes and improvements to the documentation. When these final touches are complete, the build goes into production and distribution to the end-users. This is also known as “general availability” or “gold candidate”.
	https://instabug.com/blog/alpha-vs-beta-apps/
	https://stackoverflow.com/questions/46786486/alpha-beta-snapshot-release-nightly-milestone-release-candidaterc-whe

	RC = Release candidate; probably feature complete and should be pretty stable - problems should be relatively rare and minor, but worth reporting to try to get them fixed for release.
	GA = General availability (a release); should be very stable and feature complete

	++++++++++++++++++++++++++++++++++

	Alpha:
	The alpha phase of the release life cycle is the first phase to begin software testing (alpha is the first letter of the Greek alphabet, used as the number 1). In this phase, developers generally test the software using white-box techniques. 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
	Alpha software can be unstable and could cause crashes or data loss. Alpha software may not contain all of the features that are planned for the final version. In general, external availability of alpha software is uncommon in proprietary software, while open source software often has publicly available alpha versions. 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.

	Beta
	"Beta Test" redirects here. For the film, see Beta Test (film). Beta, named after the second letter of the Greek alphabet, is the software development phase following alpha. Software in the beta stage is also known as betaware. Beta phase generally begins when the software is feature complete but likely to contain a number of known or unknown bugs. Software in the beta phase will generally have many more bugs in it than completed software, as well as speed/performance issues and may still cause crashes or data loss. 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 and this is typically the first time that the software is available outside of the organization that developed it. Beta version software is often useful for demonstrations and previews within an organization and to prospective customers. Some developers refer to this stage as a preview, preview release, prototype, technical preview / technology preview (TP), or early access. Some software is kept in perpetual beta, where new features and functionality are continually added to the software without establishing a firm "final" release.
	Beta testers are people who actively report issues of beta software. They are usually customers or representatives of prospective customers of the organization that develops the software. Beta testers tend to volunteer their services free of charge but often receive versions of the product they test, discounts on the release version, or other incentives.
	As the Internet has facilitated rapid and inexpensive distribution of software, companies have begun to take a looser approach to use of the word "beta". In February 2005, ZDNet published an article about the recent phenomenon of a beta version often staying for years and being used as if it were in production level, disparagingly called "perpetual beta". It noted that Gmail and Google News, for example, had been in beta for a long period of time and were not expected to drop the beta status despite the fact that they were widely used; however, Google News did leave beta in January 2006, followed by Google Apps, including Gmail, in July 2009. This technique may allow a developer to delay offering full support and responsibility for remaining issues. In the context of Web 2.0, people even talk of perpetual betas to signify that some software is meant to stay in beta state. Also, "beta" is sometimes used to indicate something more like a release candidate, or as a form of time-limited demo, or marketing technique. Since the introduction of Windows 8, Microsoft has no longer been naming their software as a beta. Instead, they have been using the term preview for most pre-release software. Since the launch of the Windows Insider Program back in 2014, all pre-release builds that are released through the program are known as Insider Preview builds.

	Snapshot and Release:
	A snapshot version in Maven is one that has not been released.
	The idea is that before a 1.0 release (or any other release) is done, there exists a 1.0-SNAPSHOT. That version is what might become 1.0. It's basically "1.0 under development". This might be close to a real 1.0 release, or pretty far (right after the 0.9 release, for example).
	The difference between a "real" version and a snapshot version is that snapshots might get updates. That means that downloading 1.0-SNAPSHOT today might give a different file than downloading it yesterday or tomorrow.
	Usually, snapshot dependencies should only exist during development and no released version (i.e. no non-snapshot) should have a dependency on a snapshot version.

	Nightly:
	A nightly build is a neutral build that takes place automatically. These typically take place when no one is likely to be working in the office so that there are no changes to the source code during the build.
	Nightly builds are a good thing, they provide immediate feedback to developers if they broke the build. Having a nightly build means that the software stable and is likely to build for new users. Software that is not built regularly is difficult to release.

	Milestone:
	Milestone versions include specific sets of functions and are released as soon as the functionality is complete.

	Release Candidate [RC]:
	Release candidate. A release candidate (RC), also known as "going silver", is a beta version with potential to be a final product, which is ready to release unless significant bugs emerge.
	Release Candidate (RC) is the build released internally to check if any critical problems have gone undetected into the code during the previous development period. Release candidates are NOT for production deployment, but they are for testing purposes only.

	+++++++++++++++++++++++++++++++++++

	Alpha Build:
	The first alpha build is the first working version of your app, which doesn’t always have the full features implemented. It is often too buggy to be usable, but contains, at a minimum, the core functions of the app ready for testing.
	Developers will add any missing features and, along with QC, focus on finding, tracking, and squashing as many bugs as they can find. When the app becomes “feature complete” and no major crashes or bugs remain, the alpha phase is considered complete and the final build then becomes the first beta version.
	Traditionally, you would conduct alpha tests internally without involving anyone outside the development cycle, however, using external testers or even end-users for the alpha phase is not unheard of. In fact, it has recently become relatively more popular among smaller development teams that don’t have a dedicated QC team.

	Beta Build:
	The beta build is the version marking the completion of the app’s development. Traditionally at this stage, no new features are added and focus becomes on improving the quality, usability, and overall experience. Beta is the first build available to users outside development and can still suffer from bugs and stability issues. However, it should not have any major issues and is considered a full-featured, usable version.
	Beta testing programs can either be closed with access restricted to invited members or open where anyone can participate. Either way, the app is tested in “real world” environments with “real world” scenarios by external testers/users. Due to the greater diversity of device environments and use patterns, this helps uncover many bugs that slipped through earlier test phases. The developers will then use the submitted bug and crash reports to pinpoint and fix all the reported defects and iterate on the builds until the application is ready for release.
	Since beta testing is the first time users get to try the app, it is the first opportunity for validation. Currently, most beta builds utilize tools to allow in-app communication, in-app surveys, track in-app behavior, and automate bug and crash reporting to maximize the feedback they receive about functionality, usability, and feature requests. If feedback uncovers major flaws in features or functionality, the team will address them before release; otherwise, the feedback is implemented in the next iteration.

	Nightly Build:
	Honoring the principle of “integrate early, integrate often”, as the name suggests, the nightly build changes every night. It is an automated build that is made at the end of the day by incorporating all the changes made during that day. They are not restricted to any stage of the development lifecycle and are used throughout the cycle, i.e. during alpha/beta testing (or any other stage of development). A nightly build is produced every day reflecting any changes to the code.
	Nightly builds are typically not accessible to anyone outside the development lifecycle but are sometimes shared with select external testers. They are on “the bleeding edge” of development and can be buggy and unstable. A nightly build towards the end of a beta cycle should be stable while one at the beginning of the alpha test is not usable.

	Production Build:
	When you iterate enough on the beta build to be stable and no new bugs or feedback is being received, QA will mark it as a “release candidate” (also called “going silver”). At this point, developers will not make any changes to the app except for minor code fixes and improvements to the documentation. When these final touches are complete, the build goes into production and distribution to the end-users. This is also known as “general availability” or “gold candidate”.