What does rc stand for? when to use alpha, beta and dev instead? how to name your projects


project_name-7.25-1.0-alpha
project_name-7.25-1.0-beta1
project_name-7.25-1.0-dev2
project_name-7.25-1.0-rc3
project_name-7.25-1.0-stable4
project_name-7.25-1.0-unstable5


following best practices?
See Drupal.org for release naming conventions and
further explantion.

Summary:

rc = Release Candidate, deemed suitable by the author for production sites.

rc: A release candidate should only be created when the all critical bug type issues are reported fixed in the project's issue queue. This tag should only be used when the developer believes that the project is ready for use on a production site. There is no official best practice for how long a project should be a release candidate before creating a official .0 release, but it is suggested that it should be out for at least a month with status set to "needs review".  If something (e.g. a new critical bug is reported) makes it necessary to create a new release during this period, a new release candidate should be created and this should remain for at least a month with status set to "needs review".

It is OK to tag a module "rc" with feature requests issues outstanding.  Module authors are not required to fulfill every feature request users of the module post to the issue queue.

Here is a description of the other allowed release tags:

unstable: The project is not in a stable state.  There are probably numerous unfixed bugs, including security issues. The API may change without notice.  The database schema may change without hook_update_N beeing implemented. Usage and API may not be documented. Installing a new unstable release entails uninstalling the project, thereby losing all data.  Only for those who want a early preview of the project.  Not yet suitable for shared development.

alpha: Most reported errors are resolved, but there may still be serious outstanding known issues, including security issues. Project is not thoroughly tested, so there may also be many unknown bugs. There is a README.txt/README.md that documents the project and its API (if any). The API and DB schema may be ustable, but all changes to these are reported in the release notes, and hook_update_N is implemented to preserve data through schema changes, but no other upgrade/update path. Not suitable for production sites. Target audience is developers who wants to participate in testing, debugging and development of the project.

beta: All critical data loss and security bugs are resolved.  If the module offers an API, it should be considered frozen, so that those using the the API can start upgrading their projects.  If it is an upgrade or update of a project, an upgrade/update path should be offered, and it should be possible for existing users to upgrade/update to the new version without loss of data.  All documentation should be up to date. Target audience is developers who wants to participate in testing, debugging and development of the project, and developers of other projects that interfaces the project. Not generally suitable for production sites, but may be used on some production sites if the site administrator knows the project well, and knows to handle any remaining issues.

The strings "dev" and "stable" are not valid as part of a release tag, but untagged development releases are assumed to be "dev" and are given descriptions such as "7.x-1.x-dev" by the Drupal.org release packing system to indicate that they are untagged development releases.

All release tags must end with a number.  The numbers are just to distinguish releases of the same class.  The first is numbered "1" (as in "alpha1"), the next "2", and so on.

PS. The strings denoting releases (such as "7.x-1.0-alpha4") are known a "release tags" in git parlance, not "names".  And you never use the drupal minor version as part of a tag, you use "x" instead.