Re: Release/Revision standard notation?

VCS is OK with me (one of my guys uses one) as long as each formal release is exported and released as a self-contained package of sources, scripts, and tools, sufficient to do a full build without the VCS.

Personally, I can control my revs and versions without one. Sometimes we pass a file-ownership token between guys. It's a piece of wood with TOKEN painted on.

John

Well actually if you think about you have proved my point, that the customer was lucky that SOMEBODY had archived the tools and systems otherwise the data was almost useless.

We do archive tools to a server, which gets weekly backups. And we rolled all our old DOS PADS jobs forward into the newer Windows format before we retired the DOS machines.

We also release duplicate PDFs of drawings in proprietary formats, so that anyone can see them, roughly forever.

John

In article , snipped-for-privacy@highNOTlandTHIStechnologyPART.com says...>

Do test the entire process on every OS release and hardware upgrade?

That's the minimum that should be done. I'll have to see what we're doing along those lines. At least there is a manual path back from "disaster".

It would not have been useless. I would have searched and searched until the old SW tool and a contractor with the necessary skills are found.

Counting on old SW tools running on a modern PC, with who knows what variant of Wimpows, is very dangerous.

While I do maintain archives in native SW language, I also archive device model and symbol libraries (text), netlists (text) and PDF versions of all schematics.

I would hate to have to re-enter such stuff into a new SW, but I have done it... like some ancient SDT III stuff for which the symbol libraries went bye-bye :-(

...Jim Thompson

No. Whenever the tools change, we dump another set into the M:\TOOLS folder, where the M-drive is our library server. That's probably enough to untange the mess if we really need to go back and rebuild an ancient software product.

All my assembly stuff uses batch files and programs that run under DOS or the Windows command line. That includes a few homebrew things that we have the source code for. So far, I've been able to rebuild 10-12 year old stuff with no problems.

I won't let any of my guys use tools that we can't archive and be reasonably sure we can run a decade or two into the future. If they use a VCS, each formal release must be a set of clean files, all on its own, independent of the VCS. And the next rev must start from those released files, not from what the VCS thought the last formal release was. KISS.

John

Nope. All the DOS stuff I still need does run on all machines here. Of course there is no Vista in this here consulting office.

Other trick: I recently installed Sun VirtualBox. That allows multiple virtual machines. If the Romans had any operating system even that would probably run. I tried Linux on it and when clicking that tab the whole Windows PC feels like a Linux PC. Nice thing is, after some tricks you can effortlessly scoot back and forth between OS'es and even copy-paste across platforms.

So far the only thing that presented a bump in the road to backward compatibility was that old Borland runtime bug. But there is a massaging routine you can send your *.exe through that will fix it even if you don't have the source code for a re-compile.

Same here.

You mean, you "lost" the symbol libraries?

When I have my druthers I might fire up ye olde SDT-III again. It was one of the best products since sliced bread.

I think that rules out most Microsoft compilers? :-)

On Windows Vista, nothing prior to Visual Studio 2005 is officially supported... although it turns out that Visual Studio 6 from 1998 will 99% work with very minor workarounds. Of course, those workarounds are not found on Microsoft's web site :-( ...but Google knows where they are.

That's an entirely reasonable process that I doubt anyone would object to. I believe in "management by interfaces" -- use whatever tools you feel like, but when it comes time to release, we have a well-defined "interface" that says what your code has to do... or, in your case, how the code needs to be built.

---Joel

VirtualBox is great. I use it "the other way round", i.e. linux host, windows guest(s). I do all my "windows" development and testing on it (Visual C++). You can also have all the different windows variants installed as separate images for software testing. When you have finished testing, just roll it back to the virginal "snapshot" for next time.

I use both Windows and Linux guests in VirtualBox (on a Windows host). If you've got two Ethernet ports on your host PC, a cunning trick is to set up a bridge on the host with the second Ethernet port, and connect the port physically to your network. Then make host interfaces in VirtualBox and connect them to the bridge, and use them instead of NAT to your host. It gives you a much more direct networking connection.

I have not needed to delve into the networking yet - everything seems to work fine as it is. I did create a shared folder link so that my linux home directory appears as a drive letter in VirtualBox.

I was surprised how good the hardware support is. It creats some kind of "virtual" USB controller, so you can use any USB device with the manufacturers drivers.

I also use the "headless" mode where you can connect using a remote desktop ("rdesktop") session. So I can be working in the office, then move to the "lab" machine and carry on using that same session.

A networking setup like mine is particularly useful if the host is windows. Linux has vastly more networking tools, so my VirtualBox setup lets me run these in a virtual Linux box (the NAT networking can't pass anything other than UDP and TCP/IP packets - no pings, arpings, or other protocols). It is also useful if you want to access the virtual machine directly on the network from other machines.

I've found it can be a little unstable at times, but apart from that it is *very* useful using USB devices in the virtual machines. It's particularly useful if the drivers for the devices are not too great, or have conflicting versions, or if you want to test installation routines. Just make a snapshot of the virtual machine before they are connected, then try it out. If it doesn't work, you can quickly roll back.

Also I don't feel the need to run AV software on the Windows VM, or keep it continuously updated. Although *theoretically* still needed, I don't do much browsing or read email from Windows (and when I do it is with firefox). So that in itself speeds things up enormously.