Release/Revision standard notation?

[asdf]

Hi all,

Can anyone tell me the format behind "Revision/Release" notation? For
example: Rev. 1.30.35; which is so common in software (and some hardware).
Is it an arbitrary system? I've tried searching for it, but come up empty
handed. I've been able to query on this:

IEEE standard taxonomy for software engineering standards

but, I keep coming up with sites that want me to pay for the article. Not to
mention the fact that the above article will have way more information that
I'm looking for. I can't think of what else to search on.

Any help?

Thanks,

Scott

 

[Rich Grise]

On Fri, 05 Dec 2008 16:57:02 -0500, asdf wrote:

Can anyone tell me the format behind "Revision/Release" notation? For
example: Rev. 1.30.35; which is so common in software (and some hardware).
Is it an arbitrary system?

Pretty much, yeah.
By convention, typically it's Version.Revieion.release number.

Hope This Helps!
Rich

 

[asdf]

Gentlmen,

Thank you. It was one of those questions that popped into my head, making me
wonder what the rhyme or reason was for the way it was done. As always, I'm
grateful for the info...

Take care,

Scott
"asdf" <sadf@sdff.com> wrote in message
news:GqWdnbaUBv42PqTUnZ2dnUVZ_gudnZ2d@earthlink.com...

Hi all,

Can anyone tell me the format behind "Revision/Release" notation? For
example: Rev. 1.30.35; which is so common in software (and some hardware).
Is it an arbitrary system? I've tried searching for it, but come up empty
handed. I've been able to query on this:

IEEE standard taxonomy for software engineering standards

but, I keep coming up with sites that want me to pay for the article. Not
to mention the fact that the above article will have way more information
that I'm looking for. I can't think of what else to search on.

Any help?

Thanks,

Scott

 

[Jasen Betts]

On 2008-12-05, asdf <sadf@sdff.com> wrote:

Hi all,

Can anyone tell me the format behind "Revision/Release" notation? For
example: Rev. 1.30.35; which is so common in software (and some hardware).
Is it an arbitrary system? I've tried searching for it, but come up empty
handed. I've been able to query on this:

the numbers are whole numbers (not decimal fractions)

1.10.1 is newer than 1.9.1

 

[Joerg]

John Devereux wrote:

John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> writes:

A hardware top assembly could be 28A346-3B, where -3 is a version
(literally the "dash number") and B is the rev. This is basic
aerospace notation.

How do you define the difference between a "version" and a "revision"?

Versions are not 100% compatible amongst each other, more geared towards
special uses. Revisions ideally are interchangeable but may, for
example, require firmware adaptations.

Are all version 3 products interchangeable, for example?

Not necessarily, I'd even say usually not. Revisions, however, should be
form-fit-function compatible or one should rather issue a new version.
In med/aero there are very strict rules about this.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

 

[John Larkin]

On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux
<john@devereux.me.uk> wrote:

John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> writes:

A hardware top assembly could be 28A346-3B, where -3 is a version
(literally the "dash number") and B is the rev. This is basic
aerospace notation.

How do you define the difference between a "version" and a "revision"?

Are all version 3 products interchangeable, for example?

A dash number distinguishes an assembly option. This might be a board
stuffing version, a firmware difference (enabling a feature, for
example) or some other variant.

An assembly drawing might be 22A375 rev B. The product might be sold
with SMB, SMA, or LEMO connectors. So we might sell physical items
22A375-1B, 22A375-2B, and 22A375-3B. If we revise the PC board, the
assembly drawing and the associated products would roll to rev C. Note
that drawings don't have dash numbers, they describe dash numbers.
Physical parts have dash numbers.

A 22A375-3C gadget may well have some features that the 22A375-3B
didn't. We try to keep later revs supersets of older ones, so that
existing customers can buy the newer revs and not have problems.

In the aircraft industry, and odd dash numbered thing (like part
12345-1A) was a part, and the following even dash number 12345-2A was
its mirror image. We don't build airplanes, so we just use sequential
dash numbers to identify versions of a basic assembly.

An assembly or fabrication drawing, unless otherwise noted, assumes
"-1 shown". A flag note on that drawing might say "for -2, drill 0.125
thru, 4 places." For electronic assemblies, dash numbers are usually
just associated with different BOM's (parts lists), so that we can
just release a new parts list to create a new dash number at any time,
without having to revise the released assembly drawing.

We use dash numbers for customer-specific versions, too. 22A375-11B
might be a standard version with an ECO applied.

All the above is pretty much mil/aerospace standard documentation
control.

Lots of people use the next available integer for the drawing number
of anything that's drawn. Then they need some side mechanism, like a
product structure document, to correlate things. We use

22A375 assembly drawing. "22" is our VME series.
A customer might order a "V375" module.
22D375 pc fab ("drill") drawing
22M375 front panel fab. M = mechanical fab dwg
22M376 cover plate fab maybe
22R375 reference drawing, design notes maybe

22E375 embedded firmware. Source is 22E375C.MAC;
obj is 22E375C.ROM

22C375 FPGA design. Config file is 22C375A.RBT

like that. It keeps things together.

Everything is formally released, archived, backed up. 10 years later,
we know exactly what was built when, and can build exact copies if we
need to.


John

 

[David L. Jones]

On Dec 6, 7:57 am, "asdf" <s...@sdff.com> wrote:

Hi all,

Can anyone tell me the format behind "Revision/Release" notation? For
example: Rev. 1.30.35; which is so common in software (and some hardware).
Is it an arbitrary system?

It's arbitrary in the sense of how people implement it, but it
generally has a reasoning behind it.

For a X.YY.ZZ system, generally speaking:

X is the major revision number. It usually changes when the software
or system undergoes radical change. i.e. new user interface,
operation, file formats or whatever.

YY usually gets updated for major release changes. Many people don't
go beyond this.

ZZ changes are trivial changes, often internal changes between
official releases.

The (software) company I work for on top of that has a 5 digit
automatic "build" number as well (X.YY.ZZ.NNNNN). Builds happens three
times a day and NNNNN gets automatically incremented.

Hardware rarely goes beyond X.Y

Dave.

 

[John Larkin]

On Mon, 8 Dec 2008 04:01:50 -0800 (PST), "David L. Jones"
<altzone@gmail.com> wrote:

On Dec 6, 7:57 am, "asdf" <s...@sdff.com> wrote:
Hi all,

Can anyone tell me the format behind "Revision/Release" notation? For
example: Rev. 1.30.35; which is so common in software (and some hardware).
Is it an arbitrary system?

It's arbitrary in the sense of how people implement it, but it
generally has a reasoning behind it.

For a X.YY.ZZ system, generally speaking:

X is the major revision number. It usually changes when the software
or system undergoes radical change. i.e. new user interface,
operation, file formats or whatever.

YY usually gets updated for major release changes. Many people don't
go beyond this.

ZZ changes are trivial changes, often internal changes between
official releases.

The (software) company I work for on top of that has a 5 digit
automatic "build" number as well (X.YY.ZZ.NNNNN). Builds happens three
times a day and NNNNN gets automatically incremented.

Hardware rarely goes beyond X.Y

Dave.

I've seen software rev 4.02b, where b is the patch level. This was
from Microsoft, I think.

John