Re: Release/Revision standard notation?

Yep, same here.

Then make sure you never use any dongled SW because that could seriously throw a wrench in there.

I try to be a nice guy, and one of the ways that I try to be a nice guy is to be sensitive to those times when a vendor really doesn't want me to be a customer. When a vendor starts throwing out subtle "we don't want your business" clues, I do my best to find an alternate source, and allow the grumpy vendor to go on with their business free of an risk of getting my money.

Dongles are, IMHO, one way that a vendor screams "we don't want your business, thank you".

Complete agreement in this here office :-)

I have never bought dongled SW in over 20 years. Not one.

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

Are all version 3 products interchangeable, for example?

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

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.

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.

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' =3D base platform, core feature set, etc.; 'yyy' =3D feature additions; 'zzz' =3D bug fixes. Then again, it might not.

As with so many things, "it depends".

JM

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

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

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

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

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

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

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

It can be much worse, though.

If someone in the decision chain

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

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

At your company, perhaps yes.

At a poorly-run company, yes.

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

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.

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

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?

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

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.

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

John

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

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

In article , snipped-for-privacy@hotmail.com=20 says...>=20

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

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