Its always benefecial to have the version number of a project clearly defining its current, past and future state. Some of the techniques are discussed below.
X.Y.Z. versioning
The common versioning sceme is X.Y.Z.
Z -> pure bug fix releases (can only change function implementation)
Y -> can introduce new functions, new symbolic and enumerated constants, and deprecate existing functions
X -> Any kind of change can be made during a major version release (New features etc.)
The main difference between these three version numbers are Forward and Backward compatibility.
For more info, please have a look at the Apache page,
or
Alpha-numeric versioning
Another approach is using an alpha-numeric string, i.e.
1.0b1, 1.0b2 (with some fixes), 1.0rc1 (stable enough)
1. Pre-alpha - prior to testing (different milestones)
2. Alpha - first phase to begin software testing (usually ends with a feature freeze)
3. Beta - feature complete, for usability testing. often useful for demonstrations and previews within an organisation and to prospective customers (preview, prototype, technical preview (TP), or early access)
4. Open and closed 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, sometimes to anybody interested
5. Release candidate - code complete when the development team agrees that no entirely new source code will be added to this release
6. Release - RTM - Release to manufacturing or Release to marketing - delivered or provided to the customer
- GA - General Availability - commercialization activities completed. software has been made available to the general market either via the web or physical media
Android versioning
On Android, we've 2 options for versioning, one for public release, the other for internal debug releases, called,
versionCode, i.e."2" and versionName, i.e."0.0.0.25" respectively.
The company should follow the standard that suits its needs.
No comments:
Post a Comment