Development of a commercial software product is a never-ending process. As soon as we publish new features, you want more. And, oh, don’t forget about the constant effort to improve your meshing experience through defect repair and performance improvements. Sometimes even the most obscure fix can have significant impact on your own delivery schedule. Your success is our success, so we’ll do whatever we can to help you meet a deadline.

In the old days (yes, I can say that now that I’ve been in the business for over 25 years), a user would report a bug and then hope to get a fix within a few months. In the modern era of instant gratification via the internet, elevated expectations and competitive open source efforts have put our developers under increasing pressure to publish fixes and new features much more rapidly.

Happier Days

Most of us remember Fonzie’s favorite (and default) comeback, “sit on it.” For a commercial software product it’s simply not feasible, and actually quite frustrating for both us and you, to warehouse bug fixes for weeks or months. We used to let some much-anticipated features collect dust on the shelf for up to a year — that’s just “wrongamundo.”

So, a few years ago, around the time of the initial release of Pointwise V16, we overhauled our development process to become more flexible. For some of us (the old guard), this required a slight adjustment to how we approach our work on a daily basis. We have sufficient staff to work simultaneously on critical bug fixes as well as enhancements to meshing algorithms, workflow and user experience. The direct result is that we can produce code that can be released every couple of weeks, or even daily for users with high priority needs.

Pointwise Releases

Internally, we categorize our software releases as major, minor or candidate.

Hybrid mesh generated with Pointwise’s T-Rex for a proposed IndyCar 2012 design. Image from Swift Engineering.

A major release will almost always contain some significant new feature or meshing technology. For example. V17.0R1 was the initial release of the T-Rex anisotropic block mesher. Since a major release contains significant changes, they require a lot of manual documentation and testing. As such, we target these about twice a year. A major version number always ends in R1, advancing at least the number after the dot — V17.2R1 will be our next major release as of this writing.

A minor release will always contain a variety of bug fixes, but can also include some new features if they’re deemed ready for prime time. Many times these are simply tweaks to the user interface, but sometimes it can be a complete overhaul of a dialog panel, or even a meshing algorithm. For example, V17.1R2 included a completely redesigned algorithm for anisotropic cell (prism) recombination. Minor versions are fully tested and documented, but since the scope of changes is much less than a major release, they’re typically faster to turn around. We target minor releases no more than 8 weeks apart. A minor version number always ends in Rn, where n is always greater than 1 — V17.1R3 will be our next minor release.

A candidate release is just that: a minor release candidate. About every two weeks, we gather up the bug fixes and minor enhancements, ensuring that all automated quality tests have passed, package and copy them up to our FTP site. Since these are not tested manually (other than normal everyday use), there’s no fanfare and you won’t find a link to them on our website. However, if you’re a customer for whom we’ve fixed an issue, we’ll send you an e-mail so you can try it out. Candidate version numbers are the next minor release version number followed by Cm, where m is the candidate number — V17.1R3C1 will be our next candidate release.

Pointwise A-Plenty

Wow, that seems like a lot of releases to keep up with. So you ask, how do we manage all of that, and keep work-in-progress separate from code that we want to publish? Simple: code branches. Our version control system allows us to create snapshots or branches of code at any point and continue development along independent paths. Our main trunk contains the latest code that we’re working on for the next major release, whereas our candidate branch contains all the bug fixes and features we want to release as soon as possible. We’re continuously integrating (merging) these branches so that bug fixes are incorporated everywhere, all the time. We also have branches for special projects, or features that may take much longer to implement than a normal major release cycle.

Frequent releases also means a lot of different versions of Pointwise that can be in your hands at any time. When you contact our support team to ask a question about how something works, or to report a bug, the first question they’ll ask you what version you’re running. [You can find the exact version and build number at the top of the Help/About window.] This tells our development and support personnel which version of the code to use when reproducing an issue or analyzing a problem. For older releases, we sometimes have to rewind the clock and build the code from source. Since we rigorously label (or tag) source code revisions when we build a release, this is a relatively quick and painless activity.

Quality, Not Quantity

It’s been said countless times: No software is ever complete. We know this to be a fact since we’re continuously improving ours. Release quality has at least as much value as frequency. Once in a while, testing will reveal some unacceptable or unexpected behavior, and this can delay a release. Balancing frequency and quality can sometimes be a challenge, but we have the tools and experience to manage this very effectively.

Rest assured that all releases, from candidate to major, are subjected to daily doses of strenuous, automated testing many times before they ever leave our hands. Major and minor releases undergo an additional period of hands-on testing to catch any potential missed implementation detail and assure that one bug fix doesn’t cause something else to break. [One statistic that you might find interesting is that most of the bugs in our tracking system are logged as a result of internal quality assurance testing, not from customer reports. On the other hand, we probably have more feature requests in our system from customers than from internal sources.]

If you want to make sure you have the latest production release, it’s always available from our website at www.pointwise.com/download.