[Tutor] Revision codes
dman
dsh8290@rit.edu
Sun, 13 Jan 2002 20:08:51 -0500
On Sun, Jan 13, 2002 at 07:20:59PM -0500, Grimmtooth wrote:
| > Defining revision codes, how when and whyfore.
| >
| > version #.#.#
| > major/significant/minor, hugher numbers being newer than smaller ones.
|
|
| I have no idea what the /de facto/ standard in opensourceworld is, but
| within my workplace, we use the following:
|
| > Start with 1.0.0;
|
| We call the three major.minor.revision
major.minor.micro (at least, that's what 'configure' scripts call the
variables.
| Revisions are bumped for bugfixes of a release. Therefore, we release
| 1.00.00, we fix a bug we bump to 1.00.01.
|
| Minors are bumped when changes to the software require revision of the
| documentation. Add a new menu to the software, bump the minor. Thus going
| from 1.00.01 and adding a new menu, we go to 1.01.00.
|
| Majors are bumped arbitrarilly, but generally reflect a major design change.
| For example, if we add a new peripheral type to the software, we go from
| 1.01.00 to 2.00.00. Or if we add a new platform, we also bump the major.
Right.
| I have also seen the use of two-digit to be literal: i.e. 2.1 is not the
| same as 2.10. So be sure to fix yourself on one right away.
Of course :
1 != 10
:-). You're allowed more than ten releases.
-D
--
Through love and faithfulness sin is atoned for;
through the fear of the Lord a man avoids evil.
Proverbs 16:6