Driver to drive?

[Tim Wescott]

On Fri, 05 Dec 2008 17:25:32 -0800, John Larkin wrote:

On Fri, 5 Dec 2008 16:57:02 -0500, "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:

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




The 4.00.02b notation is crap, and I can't see any patterns in actual
use.

It can be useful if you exercise discipline. There are a number of
different patterns in use. They overlap, so with your attitude you
wouldn't be able to discern them. There are no standards, so any
"pattern of use" is up to the authors of the software.

But as soon as Marketing starts using them, they get pretty close to
crap...

As engineers, we use revision letters for code and for hardware. A piece
of embedded firmware is 28E346 rev A; the next release is B. All the
source files are named in the same pattern... assembly source is
28E346A.MAC and the associated FPGA config file might be 28C346A.RBT.
The shippable binary might be 28E346A.ROM.

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.

Before it defines a product, hardware and firmware documentation is
formally released to the company library, with a genuinely useful README
file, which library is where manufacturing always gets stuff from. And
it's all tested *before* it's released!

We also require that all software tools be identified, version
controlled, and released to the library too. So 10 years from now we can
run one batch file to regenerate the whole build, and know we'll get
exactly the same firmware, byte for byte.

_Any_ revision control system is only as good as the discipline and
integrity of the people running it. If someone in the decision chain
decides to chip rev B even though it's crap and no one can replicate it,
then the "A, B, C" rev system becomes crap. If _everyone_ in the
decision chain decides to do their job right then a "number, dot" system
will work just as well as an "A, B, C" system.

So I don't buy your assertions in the least.

--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

 

[John Larkin]

On Sun, 7 Dec 2008 09:45:17 -0800 (PST), John Mianowski
<spamfree@skytex.net> wrote:

On Dec 7, 11:01 am, John Devereux <j...@devereux.me.uk> wrote:
John Larkin <jjlar...@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"?

I've seen a lot of different variations between industries, companies
within industries, etc. Sometimes you'll see it expressed as "VxRy"
or some variation that makes it a little easier to visualize.
Basically, there are 3 "levels" of change. The top level represents
basic, fundamental issues such as platform, core, basic features &
capabilities, etc. The next level might represent "secondary"
features, added to the primary ones at the top level. The 3rd level
would be changes based on problem corrections, that don't add any
particular feature or capability.

As an example, a company I used to work for used "V" numbers to define
the core processor & basic architecture generation of the system. V1
was the original, 8080-based system; V2 was 8086-based & fit the same
cabinets, but included some major changes to the inter-processor
communications & disk subsystems. V3 was a complete repackaging, with
upgrades to several subsystems but retention of the same CPU & inter-
processor comm. V4 was a consolidation & downsizing. V5 was another
complete repackaging with several upgrades to subsystems.

Within each Version 'x' were several revisions. Each revision level
introduced some new major features..Within each Revision 'y' were
potentially many lettered "Sub-revisions" that included bug fixes &
sometimes a new, minor feature. Sometimes, a R-level upgrade required
a corresponding hardware and/or firmware upgrade to go with it.

Are all version 3 products interchangeable, for example?

Maybe, maybe not. In the above example, V2R05A & V3R05A would
represent identical levels of feature enhancements & bug fixes, but
due to the base hardware platform differences between V2 & V3, neither
would run on the other platform. Also, V3R07A might not be backward-
compatible with V3R05C due to an hardware/firmware change(s) somewhere
in the system, to accommodate features in R7 that weren't in R5.
Generally, with a VxRy there was universal compatibility (i.e. you
could go back & forth between V3R8x & V3R8y with no problem other than
the possible reintroduction of bugs; sometimes a subrelease to "fix"
one bug created another, creating a need to accept the lesser bug
temporarily & revert to a prior level). Different "V" levels may also
have different "R" levels as well. Sometimes, a bug appears entirely
due to the change in "top" level so there's no corresponding need to
"fix" it in a prior level, since it doesn't exist there. Also, prior
"top" levels may become obsolete, with both feature enhancements and/
or bug fixes suspended.

The 'xxx.yyy.zzz' notation might represent similar levels, such as
'xxx' = base platform, core feature set, etc.; 'yyy' = feature
additions; 'zzz' = bug fixes. Then again, it might not.

As with so many things, "it depends".

JM

What you describe is closer to the fuzzy 2.10.04b software convention.
The mil/aerospace drawing control procedure isn't so much focussed on
functionality or features, but rather in documenting *precisely* what
was built, assuring the we understand the exact configuration of every
unit in the field, and guaranteeing that we can *exactly* replicate,
down to the last byte and tie-wrap, any previously built item.
Anything less can kill people.

John

 

[John Larkin]

On Sun, 07 Dec 2008 13:43:34 -0600, Tim Wescott <tim@seemywebsite.com>
wrote:

On Fri, 05 Dec 2008 17:25:32 -0800, John Larkin wrote:

On Fri, 5 Dec 2008 16:57:02 -0500, "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:

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




The 4.00.02b notation is crap, and I can't see any patterns in actual
use.

It can be useful if you exercise discipline. There are a number of
different patterns in use. They overlap, so with your attitude you
wouldn't be able to discern them. There are no standards, so any
"pattern of use" is up to the authors of the software.

But as soon as Marketing starts using them, they get pretty close to
crap...

As engineers, we use revision letters for code and for hardware. A piece
of embedded firmware is 28E346 rev A; the next release is B. All the
source files are named in the same pattern... assembly source is
28E346A.MAC and the associated FPGA config file might be 28C346A.RBT.
The shippable binary might be 28E346A.ROM.

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.

Before it defines a product, hardware and firmware documentation is
formally released to the company library, with a genuinely useful README
file, which library is where manufacturing always gets stuff from. And
it's all tested *before* it's released!

We also require that all software tools be identified, version
controlled, and released to the library too. So 10 years from now we can
run one batch file to regenerate the whole build, and know we'll get
exactly the same firmware, byte for byte.

_Any_ revision control system is only as good as the discipline and
integrity of the people running it.

It can be much worse, though.


If someone in the decision chain

decides to chip rev B even though it's crap and no one can replicate it,
then the "A, B, C" rev system becomes crap.

Only manufacturing builds and ships stuff. They get their docs only
from the company library. Stuff gets into the library only by formal
release. There are no sneak paths.


If _everyone_ in the

decision chain decides to do their job right then a "number, dot" system
will work just as well as an "A, B, C" system.

So I don't buy your assertions in the least.

Most programmers like to simply toss the whole version control issue
into a big automated VCS/SCM/bug tracking database thing. Lots of
programmers are continually checking things in and out, changing
stuff, and at some point marketing/management can't stand it any
longer and spins off a release.

I wonder if the VCS itself can still be run 10 years later. I guess it
doesn't matter, since hardly anybody supports 10-year old software. We
sure as hell have to support 10-year old products, hardware and
firmware included.

One important aspect of our doc control system is that nobody in the
decision chain gets to arbitrarily ship selected code revs on any
given hardware platform. Each shippable item is fully documented and
controlled, and only a formally released ECO, signed by the President,
allows exceptions.

This isn't hard to do. It's easy, considering the confusion that will
result from not doing all this right.

John

 

[Tim Wescott]

On Sun, 07 Dec 2008 12:09:52 -0800, John Larkin wrote:

On Sun, 07 Dec 2008 13:43:34 -0600, Tim Wescott <tim@seemywebsite.com
wrote:

On Fri, 05 Dec 2008 17:25:32 -0800, John Larkin wrote:

On Fri, 5 Dec 2008 16:57:02 -0500, "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:

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




The 4.00.02b notation is crap, and I can't see any patterns in actual
use.

It can be useful if you exercise discipline. There are a number of
different patterns in use. They overlap, so with your attitude you
wouldn't be able to discern them. There are no standards, so any
"pattern of use" is up to the authors of the software.

But as soon as Marketing starts using them, they get pretty close to
crap...

As engineers, we use revision letters for code and for hardware. A
piece of embedded firmware is 28E346 rev A; the next release is B. All
the source files are named in the same pattern... assembly source is
28E346A.MAC and the associated FPGA config file might be 28C346A.RBT.
The shippable binary might be 28E346A.ROM.

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.

Before it defines a product, hardware and firmware documentation is
formally released to the company library, with a genuinely useful
README file, which library is where manufacturing always gets stuff
from. And it's all tested *before* it's released!

We also require that all software tools be identified, version
controlled, and released to the library too. So 10 years from now we
can run one batch file to regenerate the whole build, and know we'll
get exactly the same firmware, byte for byte.

_Any_ revision control system is only as good as the discipline and
integrity of the people running it.

It can be much worse, though.


If someone in the decision chain
decides to chip rev B even though it's crap and no one can replicate it,
then the "A, B, C" rev system becomes crap.

Only manufacturing builds and ships stuff. They get their docs only from
the company library. Stuff gets into the library only by formal release.
There are no sneak paths.

At your company, perhaps yes.

If _everyone_ in the
decision chain decides to do their job right then a "number, dot" system
will work just as well as an "A, B, C" system.

So I don't buy your assertions in the least.

Most programmers like to simply toss the whole version control issue
into a big automated VCS/SCM/bug tracking database thing. Lots of
programmers are continually checking things in and out, changing stuff,
and at some point marketing/management can't stand it any longer and
spins off a release.

At a poorly-run company, yes.

I wonder if the VCS itself can still be run 10 years later. I guess it
doesn't matter, since hardly anybody supports 10-year old software. We
sure as hell have to support 10-year old products, hardware and firmware
included.

One important aspect of our doc control system is that nobody in the
decision chain gets to arbitrarily ship selected code revs on any given
hardware platform. Each shippable item is fully documented and
controlled, and only a formally released ECO, signed by the President,
allows exceptions.

This isn't hard to do. It's easy, considering the confusion that will
result from not doing all this right.

John

So, let's change the venue, and reiterate what you're saying, and analyze
it's validity:

"Apples are picked in the next farm over from me, placed in wicker
baskets and hand carried to the farm stand. I buy them and they taste
delicious."

"Oranges are picked all the way over there in Florida, put into cardboard
crates along with sharp rocks, and are shipped by unsprung trucks on dirt
roads. Then they are tossed off of these trucks into my local
supermarket's produce aisle. I buy them and they are bruised up and
taste terrible."

"Therefore stuff that comes in crates is crap and stuff that comes in
wicker baskets is excellent."

Does that sound like your claim?

So I agree with your _evidence_, but I disagree with your _conclusion_.
You may as well say that because you paint your office blue that only
blue-painted offices can generate high quality work.

If you have a software code base that has more than a couple of dozen
source files and more than one developer, then you simply aren't going to
be able to adequately keep track of modifications with anything other
than a good version control system. The stack-o-floppies works for one
or two source files and one developer, but even then it works if and only
if discipline is exerted in the development and archiving process.

(Note that I _always_ use version control for all my client's projects,
even though I'm the only developer and some of my client's code bases are
only a few files).

Trying to maintain any sort of order in a software development effort
that has multiple source files and multiple developers _without_ a good
version control system is damn near impossible. If your source is
distributed between a dozen people and resides on multiple directories,
floppies, CDs, and memory sticks, then you'll never build the same thing
twice, and you'll never get a coherent handle on what you're doing.

I would contend -- totally opposite of your assertion -- that you cannot
produce high quality software above a certain size _without_ a VCS. But
then, I think that if you tried it with the pile-o-floppy method and the
level of discipline that you rightly require, you'd figure this out
pretty quickly.

What gets you your high quality is the discipline that you exert. The
language of the labeling is as superficial as the color of paint on your
walls.

--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

 

[John Larkin]

On Sun, 07 Dec 2008 14:35:12 -0600, Tim Wescott <tim@seemywebsite.com>
wrote:

On Sun, 07 Dec 2008 12:09:52 -0800, John Larkin wrote:

On Sun, 07 Dec 2008 13:43:34 -0600, Tim Wescott <tim@seemywebsite.com
wrote:

On Fri, 05 Dec 2008 17:25:32 -0800, John Larkin wrote:

On Fri, 5 Dec 2008 16:57:02 -0500, "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:

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




The 4.00.02b notation is crap, and I can't see any patterns in actual
use.

It can be useful if you exercise discipline. There are a number of
different patterns in use. They overlap, so with your attitude you
wouldn't be able to discern them. There are no standards, so any
"pattern of use" is up to the authors of the software.

But as soon as Marketing starts using them, they get pretty close to
crap...

As engineers, we use revision letters for code and for hardware. A
piece of embedded firmware is 28E346 rev A; the next release is B. All
the source files are named in the same pattern... assembly source is
28E346A.MAC and the associated FPGA config file might be 28C346A.RBT.
The shippable binary might be 28E346A.ROM.

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.

Before it defines a product, hardware and firmware documentation is
formally released to the company library, with a genuinely useful
README file, which library is where manufacturing always gets stuff
from. And it's all tested *before* it's released!

We also require that all software tools be identified, version
controlled, and released to the library too. So 10 years from now we
can run one batch file to regenerate the whole build, and know we'll
get exactly the same firmware, byte for byte.

_Any_ revision control system is only as good as the discipline and
integrity of the people running it.

It can be much worse, though.


If someone in the decision chain
decides to chip rev B even though it's crap and no one can replicate it,
then the "A, B, C" rev system becomes crap.

Only manufacturing builds and ships stuff. They get their docs only from
the company library. Stuff gets into the library only by formal release.
There are no sneak paths.

At your company, perhaps yes.

If _everyone_ in the
decision chain decides to do their job right then a "number, dot" system
will work just as well as an "A, B, C" system.

So I don't buy your assertions in the least.

Most programmers like to simply toss the whole version control issue
into a big automated VCS/SCM/bug tracking database thing. Lots of
programmers are continually checking things in and out, changing stuff,
and at some point marketing/management can't stand it any longer and
spins off a release.

At a poorly-run company, yes.

I wonder if the VCS itself can still be run 10 years later. I guess it
doesn't matter, since hardly anybody supports 10-year old software. We
sure as hell have to support 10-year old products, hardware and firmware
included.

One important aspect of our doc control system is that nobody in the
decision chain gets to arbitrarily ship selected code revs on any given
hardware platform. Each shippable item is fully documented and
controlled, and only a formally released ECO, signed by the President,
allows exceptions.

This isn't hard to do. It's easy, considering the confusion that will
result from not doing all this right.

John

So, let's change the venue, and reiterate what you're saying, and analyze
it's validity:

"Apples are picked in the next farm over from me, placed in wicker
baskets and hand carried to the farm stand. I buy them and they taste
delicious."

"Oranges are picked all the way over there in Florida, put into cardboard
crates along with sharp rocks, and are shipped by unsprung trucks on dirt
roads. Then they are tossed off of these trucks into my local
supermarket's produce aisle. I buy them and they are bruised up and
taste terrible."

"Therefore stuff that comes in crates is crap and stuff that comes in
wicker baskets is excellent."

Does that sound like your claim?

So I agree with your _evidence_, but I disagree with your _conclusion_.
You may as well say that because you paint your office blue that only
blue-painted offices can generate high quality work.

If you have a software code base that has more than a couple of dozen
source files and more than one developer, then you simply aren't going to
be able to adequately keep track of modifications with anything other
than a good version control system. The stack-o-floppies works for one
or two source files and one developer, but even then it works if and only
if discipline is exerted in the development and archiving process.

(Note that I _always_ use version control for all my client's projects,
even though I'm the only developer and some of my client's code bases are
only a few files).

Trying to maintain any sort of order in a software development effort
that has multiple source files and multiple developers _without_ a good
version control system is damn near impossible. If your source is
distributed between a dozen people and resides on multiple directories,
floppies, CDs, and memory sticks, then you'll never build the same thing
twice, and you'll never get a coherent handle on what you're doing.

I would contend -- totally opposite of your assertion -- that you cannot
produce high quality software above a certain size _without_ a VCS. But
then, I think that if you tried it with the pile-o-floppy method and the
level of discipline that you rightly require, you'd figure this out
pretty quickly.

What gets you your high quality is the discipline that you exert. The
language of the labeling is as superficial as the color of paint on your
walls.

We manage software the same way we manage hardware, with the same
revision control procedures, the same release procedures, the same
rules, the same numbering system. We require that every shipped
product will be exactly reproducable and maintainable for decades.
Since disciplined hardware configuration management has been solidly
successful for 60 years or so, and is mandatory when lives and
gigabucks are involved, why not?

Thank goodness that most embedded product programs don't need an army
of programmers and a VCS to keep them under control.

John

 

[John Mianowski]

On Dec 7, 1:53 pm, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:

What you describe is closer to the fuzzy 2.10.04b software convention.

No surprise, that's where I come from ;-)

That's also what OP was asking about. I tried to give him an example
where I know with certainty, why it was done the way it was, because I
was heavily involved.

The mil/aerospace drawing control procedure isn't so much focused on
functionality or features, but rather in documenting *precisely* what
was built, assuring the we understand the exact configuration of every
unit in the field, and guaranteeing that we can *exactly* replicate,
down to the last byte and tie-wrap, any previously built item.
Anything less can kill people.

No argument, & I can certainly understand & appreciate the need to do
it that way. I'm always glad such systems are in place when I have to
trust my life to equipment provided by the lowest bidder!

JM

 

[John Devereux]

John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> writes:

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.

Do the revision letters *all* get bumped up together for all
"drawings"? For example if you modify the PCB, does the version letter
of the front panel get changed too? (I would assume not). Or just the
assembly drawing and the pc board?

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.

Cool, thanks. (I do need to improve our own procedures, so find this
stuff interesting).

--

John Devereux

 

[John Larkin]

On Mon, 08 Dec 2008 09:56:05 +0000, John Devereux
<john@devereux.me.uk> wrote:

John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> writes:

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.

Do the revision letters *all* get bumped up together for all
"drawings"? For example if you modify the PCB, does the version letter
of the front panel get changed too? (I would assume not). Or just the
assembly drawing and the pc board?

We roll the rev letter of the "D" drawing (pcb etch) and "A" (pcb
assembly) together. Not everybody does that, but we find it cleaner.
Some people consider a kluged rev B to be the same as a rev C with the
kluges incorporated.

We don't rev a front panel or a bracket unless it needs to be changed.
So a VME module rev D has pcb fab rev D and pcb assembly D, but may
still call out front panel fab A. That's all on the parts list.

A complex assembly, like a rackmount thing, could have multiple
subassemblies, all at verious revs. In that case, we roll the top
assembly rev letter if the form/fit/function of the main box changes
significantly.

When we test/ship anything, our test department logs all the relevant
rev letters and firmware versions for future reference.

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.

Cool, thanks. (I do need to improve our own procedures, so find this
stuff interesting).

I learned all this from having to do MIL stuff. It must be formally
documented somewhere.

John

 

[John Devereux]

John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> writes:


[...]

We roll the rev letter of the "D" drawing (pcb etch) and "A" (pcb
assembly) together. Not everybody does that, but we find it cleaner.
Some people consider a kluged rev B to be the same as a rev C with the
kluges incorporated.

I suppose the problem with your way is if the "pcb etch" letter
appears on the artwork (so that it ends up printed on the board).

We don't rev a front panel or a bracket unless it needs to be changed.
So a VME module rev D has pcb fab rev D and pcb assembly D, but may
still call out front panel fab A. That's all on the parts list.

A complex assembly, like a rackmount thing, could have multiple
subassemblies, all at verious revs. In that case, we roll the top
assembly rev letter if the form/fit/function of the main box changes
significantly.

When we test/ship anything, our test department logs all the relevant
rev letters and firmware versions for future reference.

[...]

I learned all this from having to do MIL stuff. It must be formally
documented somewhere.

John

--

John Devereux

 

[Richard Henry]

On Dec 7, 11:46 am, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:

On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux

j...@devereux.me.uk> wrote:
John Larkin <jjlar...@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

Providing that you still have a computer that can read 5.25" disks.

 

[krw]

In article <8f4bbb1b-c188-4ede-b2de-
f406e934aaaa@r36g2000prf.googlegroups.com>, pomerado@hotmail.com
says...>

On Dec 7, 11:46 am, John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux

j...@devereux.me.uk> wrote:
John Larkin <jjlar...@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

Providing that you still have a computer that can read 5.25" disks.

Well, genius, most are smart enough to migrate their business
critical data to new systems when the old get replaced.

 

[Phil Hobbs]

Tim Wescott wrote:

On Sun, 07 Dec 2008 12:09:52 -0800, John Larkin wrote:
snip
I wonder if the VCS itself can still be run 10 years later. I guess it
doesn't matter, since hardly anybody supports 10-year old software. We
sure as hell have to support 10-year old products, hardware and firmware
included.

One important aspect of our doc control system is that nobody in the
decision chain gets to arbitrarily ship selected code revs on any given
hardware platform. Each shippable item is fully documented and
controlled, and only a formally released ECO, signed by the President,
allows exceptions.

This isn't hard to do. It's easy, considering the confusion that will
result from not doing all this right.
snip
I would contend -- totally opposite of your assertion -- that you cannot
produce high quality software above a certain size _without_ a VCS. But
then, I think that if you tried it with the pile-o-floppy method and the
level of discipline that you rightly require, you'd figure this out
pretty quickly.

What gets you your high quality is the discipline that you exert. The
language of the labeling is as superficial as the color of paint on your
walls.

I don't like the Linux-style version numbering either, but it has the
advantage of giving each of probably thousands of builds a unique
identifier.

I use git for version control of everything. I standardized on it a
couple of years ago--previously I used a set of scripts to generate
zipfiles from file lists, which worked fine since almost all my stuff is
done solo. I use it for code, schematics, docs, books, articles, patent
disclosures, drawings, just about everything.

git is amazingly fast and easy to use, runs on most platforms (though
you do need cygwin if you're running Windows), and--crucially--is easy
to debug and back up.

Backing up the tools is a bit more problematical, though--you often need
the right OS revision as well, due to API and library changes. That's
one of the wonders of self-contained, statically linked executables--no
library worries. All my simulation apps are console-based for the same
reason.

Cheers,

Phil Hobbs

 

[Tim Wescott]

John Larkin wrote:

On Sun, 07 Dec 2008 14:35:12 -0600, Tim Wescott <tim@seemywebsite.com
wrote:

On Sun, 07 Dec 2008 12:09:52 -0800, John Larkin wrote:

On Sun, 07 Dec 2008 13:43:34 -0600, Tim Wescott <tim@seemywebsite.com
wrote:

On Fri, 05 Dec 2008 17:25:32 -0800, John Larkin wrote:

On Fri, 5 Dec 2008 16:57:02 -0500, "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:

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




The 4.00.02b notation is crap, and I can't see any patterns in actual
use.
It can be useful if you exercise discipline. There are a number of
different patterns in use. They overlap, so with your attitude you
wouldn't be able to discern them. There are no standards, so any
"pattern of use" is up to the authors of the software.

But as soon as Marketing starts using them, they get pretty close to
crap...

As engineers, we use revision letters for code and for hardware. A
piece of embedded firmware is 28E346 rev A; the next release is B. All
the source files are named in the same pattern... assembly source is
28E346A.MAC and the associated FPGA config file might be 28C346A.RBT.
The shippable binary might be 28E346A.ROM.

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.

Before it defines a product, hardware and firmware documentation is
formally released to the company library, with a genuinely useful
README file, which library is where manufacturing always gets stuff
from. And it's all tested *before* it's released!

We also require that all software tools be identified, version
controlled, and released to the library too. So 10 years from now we
can run one batch file to regenerate the whole build, and know we'll
get exactly the same firmware, byte for byte.
_Any_ revision control system is only as good as the discipline and
integrity of the people running it.
It can be much worse, though.


If someone in the decision chain
decides to chip rev B even though it's crap and no one can replicate it,
then the "A, B, C" rev system becomes crap.
Only manufacturing builds and ships stuff. They get their docs only from
the company library. Stuff gets into the library only by formal release.
There are no sneak paths.
At your company, perhaps yes.

If _everyone_ in the
decision chain decides to do their job right then a "number, dot" system
will work just as well as an "A, B, C" system.

So I don't buy your assertions in the least.
Most programmers like to simply toss the whole version control issue
into a big automated VCS/SCM/bug tracking database thing. Lots of
programmers are continually checking things in and out, changing stuff,
and at some point marketing/management can't stand it any longer and
spins off a release.
At a poorly-run company, yes.

I wonder if the VCS itself can still be run 10 years later. I guess it
doesn't matter, since hardly anybody supports 10-year old software. We
sure as hell have to support 10-year old products, hardware and firmware
included.

One important aspect of our doc control system is that nobody in the
decision chain gets to arbitrarily ship selected code revs on any given
hardware platform. Each shippable item is fully documented and
controlled, and only a formally released ECO, signed by the President,
allows exceptions.

This isn't hard to do. It's easy, considering the confusion that will
result from not doing all this right.

John
So, let's change the venue, and reiterate what you're saying, and analyze
it's validity:

"Apples are picked in the next farm over from me, placed in wicker
baskets and hand carried to the farm stand. I buy them and they taste
delicious."

"Oranges are picked all the way over there in Florida, put into cardboard
crates along with sharp rocks, and are shipped by unsprung trucks on dirt
roads. Then they are tossed off of these trucks into my local
supermarket's produce aisle. I buy them and they are bruised up and
taste terrible."

"Therefore stuff that comes in crates is crap and stuff that comes in
wicker baskets is excellent."

Does that sound like your claim?

So I agree with your _evidence_, but I disagree with your _conclusion_.
You may as well say that because you paint your office blue that only
blue-painted offices can generate high quality work.

If you have a software code base that has more than a couple of dozen
source files and more than one developer, then you simply aren't going to
be able to adequately keep track of modifications with anything other
than a good version control system. The stack-o-floppies works for one
or two source files and one developer, but even then it works if and only
if discipline is exerted in the development and archiving process.

(Note that I _always_ use version control for all my client's projects,
even though I'm the only developer and some of my client's code bases are
only a few files).

Trying to maintain any sort of order in a software development effort
that has multiple source files and multiple developers _without_ a good
version control system is damn near impossible. If your source is
distributed between a dozen people and resides on multiple directories,
floppies, CDs, and memory sticks, then you'll never build the same thing
twice, and you'll never get a coherent handle on what you're doing.

I would contend -- totally opposite of your assertion -- that you cannot
produce high quality software above a certain size _without_ a VCS. But
then, I think that if you tried it with the pile-o-floppy method and the
level of discipline that you rightly require, you'd figure this out
pretty quickly.

What gets you your high quality is the discipline that you exert. The
language of the labeling is as superficial as the color of paint on your
walls.

We manage software the same way we manage hardware, with the same
revision control procedures, the same release procedures, the same
rules, the same numbering system.

Good for you. An old employer of mine that I still occasionally work
for treats mechanical design work as real engineering, electrical design
work as slightly mysterious real engineering, and software design work
as strange, wacky black magic that can only be done under the light of a
lunar eclipse with the aid of a freshly dead chicken.

Hence, when a mechanical guy has a preliminary design review everyone
shows up with the expectation that they'll understand what's said, when
an electrical guy has a design review everyone shows up with the
expectation that they'll understand what's said, and when a software guy
has a review only software people show up -- if you can drag them away
from coding long enough to do so.

Drives me up the wall.

We require that every shipped
product will be exactly reproducable and maintainable for decades.

Good for you.

Since disciplined hardware configuration management has been solidly
successful for 60 years or so, and is mandatory when lives and
gigabucks are involved, why not?

Thank goodness that most embedded product programs don't need an army
of programmers and a VCS to keep them under control.

The process that seems to work when you have "big" embedded software is
to use the VCS and the platoon (_not_ army) of developers to generate
release candidates, release the binary image through the same part
numbering system that you speak of, and keep the VCS up to date (through
discipline, again) in the background to insure reproducible code.

Part of this is done by never, ever, letting a developer submit a binary
image for release -- you go out and hire at least one person who knows
how to start a build, but doesn't want to play with the code. Their job
is to build and test software, and to kick the developer in the shins if
it doesn't build or test out. If they can't check code out of the VCS
into a virgin directory, build it and have it work, then the software is
broken -- with no allowance for the developer insisting on special
gyrations to make that particular build work.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html

 

[Joel Koltner]

"Richard Henry" <pomerado@hotmail.com> wrote in message
news:8f4bbb1b-c188-4ede-b2de-f406e934aaaa@r36g2000prf.googlegroups.com...
"Providing that you still have a computer that can read 5.25" disks."

These days I suspect the best approach to "archiving" a system would be to
create a virtual machine with all the tools installed.

Although as Joerg/Tim point out, there's still a problem if any of it is
dongled.

Where I work our hardware releases are just "vX.YZ" where changes in X refer
to new physical PCBs and changes in Y usually refer to some "significant"
hacks (blue-wires -- or drilling out holes or something for mechanical pieces)
on the board whereas changes and in Z usually refer to component value
changes.

For software, we don't have any real standard, although I've generally a
proponent of just stick a timestamp (full date & time) on the release -- which
can be easily automated with the build tools. This completely eliminates the
very common problem where someone finds a bug, some programmer fixes it (or at
least attempts to), providers a test with a new binary... but the binary still
claims to be the exact same version number as the buggy release. :-(

 

[Richard Henry]

On Dec 8, 8:26 am, krw <k...@att.zzzzzzzzz> wrote:

In article <8f4bbb1b-c188-4ede-b2de-
f406e934a...@r36g2000prf.googlegroups.com>, pomer...@hotmail.com
says...





On Dec 7, 11:46 am, John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux

j...@devereux.me.uk> wrote:
John Larkin <jjlar...@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

Providing that you still have a computer that can read 5.25" disks.

Well, genius, most are smart enough to migrate their business
critical data to new systems when the old get replaced.-

"Only wimps use tape backup; *real* men just upload their important
stuff on
FTP, and let the rest of the world mirror it " -- Linus Torvalds

 

[Paul Carpenter]

In article <MPG.23a706ae1955768d9896ec@news.individual.net>,
krw@att.zzzzzzzzz says...

In article <8f4bbb1b-c188-4ede-b2de-
f406e934aaaa@r36g2000prf.googlegroups.com>, pomerado@hotmail.com
says...
On Dec 7, 11:46 am, John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux

j...@devereux.me.uk> wrote:
John Larkin <jjlar...@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.

....
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

Providing that you still have a computer that can read 5.25" disks.

Well, genius, most are smart enough to migrate their business
critical data to new systems when the old get replaced.

Migrating code for tools no longer manufactured/sold actually means
that the simpler and cost effective solution for some markets is
actually to archive complete computer systems as changing the tools
means revalidation/certification. Even if you could get the new versions
of tools to work with newer computers/operating systems/etc..

Especially if you have last time buy on components even at wafer
level because you are making parts for aircraft, classic examples
would be

Boeing 747
C130 (Hercules in UK)
Nimrod (originally Comet airframe circa late 1950's)

Having recently looked at some testing equipment that has to work for
at least 10 years, I am aware of the issues and multiple paper/CD/network
storage of documents etc..

--
Paul Carpenter | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

 

[RST Engineering (jw)]

I use git for version control of everything. I standardized on it a
couple of years ago--previously I used a set of scripts to generate
zipfiles from file lists, which worked fine since almost all my stuff is
done solo. I use it for code, schematics, docs, books, articles, patent
disclosures, drawings, just about everything.

git is amazingly fast and easy to use, runs on most platforms (though you
do need cygwin if you're running Windows), and--crucially--is easy to
debug and back up.

What is git?

Jim

 

[John Devereux]

"RST Engineering (jw)" <jim@rstengineering.com> writes:

I use git for version control of everything. I standardized on it a
couple of years ago--previously I used a set of scripts to generate
zipfiles from file lists, which worked fine since almost all my stuff is
done solo. I use it for code, schematics, docs, books, articles, patent
disclosures, drawings, just about everything.

git is amazingly fast and easy to use, runs on most platforms (though you
do need cygwin if you're running Windows), and--crucially--is easy to
debug and back up.

I use it too.

I agree is it very fast and efficient - so much so that I am
considering adding all my tools to the version control, as well as the
"documents" (source code, schematics etc).

What is git?

<http://www.google.com/search?&q=git>

--

John Devereux

 

[Phil Hobbs]

RST Engineering (jw) wrote:

I use git for version control of everything. I standardized on it a
couple of years ago--previously I used a set of scripts to generate
zipfiles from file lists, which worked fine since almost all my stuff is
done solo. I use it for code, schematics, docs, books, articles, patent
disclosures, drawings, just about everything.

git is amazingly fast and easy to use, runs on most platforms (though you
do need cygwin if you're running Windows), and--crucially--is easy to
debug and back up.

What is git?

Jim


It's the revision control system used for the Linux kernel. You can get

it at http://git.or.cz/.

Cheers,

Phil Hobbs

 

[krw]

In article <854572bd-f86b-4198-903b-9ef989bb2e73
@r15g2000prh.googlegroups.com>, pomerado@hotmail.com says...>

On Dec 8, 8:26 am, krw <k...@att.zzzzzzzzz> wrote:
In article <8f4bbb1b-c188-4ede-b2de-
f406e934a...@r36g2000prf.googlegroups.com>, pomer...@hotmail.com
says...





On Dec 7, 11:46 am, John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux

j...@devereux.me.uk> wrote:
John Larkin <jjlar...@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

Providing that you still have a computer that can read 5.25" disks.

Well, genius, most are smart enough to migrate their business
critical data to new systems when the old get replaced.-

"Only wimps use tape backup; *real* men just upload their important
stuff on
FTP, and let the rest of the world mirror it " -- Linus Torvalds

Once again, RH shows his infinite ignorance.