[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