Richard,

It's been interesting reading all of the different replies on revisions
and documentation.  I think the real answer is "it depends" on what you
need to accomplish.  Rolling revs to the top for everything takes more
effort and work, but I always thought it was the cleanest too, so it
depends on if you want to do that or not.

In my experience with several different systems, I found that
compatability or interchangeable/non-interchangable was the key for me.
Bumping a rev does make it a unique p/n, but when you have the same class
code and base number, sometimes people just don't look at the rev and it
can easily get missed.

Which brings me to another "it depends" moment.    How much intelligence
is in your p/n?  If you have fields for charting, compatability or other
items that make it easier to identify, you might do one thing and if they
are just sequential numbers, you might choose to do something else.  It
depends.

I always try to take out a new p/n for things that are not compatable and
build a whole doc package around it.  Takes extra work, but with all of
the editing, cut and paste and make from capability, I don't think its as
bad as it used to be.  With multiple CMs and offshore, it seems making it
bullet proof to whomever needs it a high priority, so a little extra doc
work is much less costly then not having it built the way you want it and
all that that entails.

One thing I did years ago was create a "Top Sheet" for the doc package,
which listed all the documentation items and their revs, along with the
ECO that changed them.  It allowed different revs for each item, but you
could see it all on the one sheet.  It worked for most items.

Like most things, experience is the great teacher, and we all have our
experiences that drive our preferences.  Mine was an artwork change to a
PWB that Engineering thought was so simple ( a few cuts and jumps on outer
layers only), that they did not want to spin the fab but just edit the
existing Rev A PWB, do the cuts and jumps and bump it to Rev B, without
taking a new p/n.  You guessed it......CM did not even notice the rev B
requirement, procures the Rev A since it had the same Class code and base
number, and we ended up with a bunch of boards that did not work.

Since then, I try to take new p/ns for any change, rather then bump revs,
for incompatable things.  Having different revs for compatable changes is
okay, but not as clean as rolling to the top, just takes a bit more work.
It depends on what you need and how much documentation push back you get,
but I always thought knowing something changed at all levels made sense.
Then there are marketing p/ns, but that's a whole different can of
worms......



---------------------------------------------------
Technet Mail List provided as a service by IPC using LISTSERV 1.8e
To unsubscribe, send a message to [log in to unmask] with following text in
the BODY (NOT the subject field): SIGNOFF Technet
To temporarily halt or (re-start) delivery of Technet send e-mail to [log in to unmask]: SET Technet NOMAIL or (MAIL)
To receive ONE mailing per day of all the posts: send e-mail to [log in to unmask]: SET Technet Digest
Search the archives of previous posts at: http://listserv.ipc.org/archives
Please visit IPC web site http://www.ipc.org/contentpage.asp?Pageid=4.3.16 for additional information, or contact Keach Sasamori at [log in to unmask] or 847-615-7100 ext.2815
-----------------------------------------------------
DJT