Dev411 Blog

In the old software days with point releases, major versions would increase from 1 to 2 to 3, etc. Releases in between major versions would point releases along the lines of 1.1, 1.2, 1.3 and smaller releases would be 1.1.1, 1.1.2, 1.1.3, etc. Then came along Windows 95 and the exit of sequential version numbers. With this naming scheme you really can't have Windows 95.1 so we now have Releases, along the lines of Oracle 11g Release 1 and Windows 2003 Server Release 2. You can pretty much guarantee that there isn't going to be an Oracle 11.1g ;)

That's all fine and good from a marketing perspective if the reason is that we are now using a year or abbreviation instead of a simple integer but are there other technical reasons? I recently upgraded from Apache httpd 2.0.x to 2.2.x and the major thing that I encountered was that configuration had changed significantly and that I had to redo my conf files. I've spoken with some people that indicated many organizations are afraid of point releases for enterprise software because they often break things and are not necessarily smooth upgrades. This fit with my Apache httpd experience which got me thinking.

If there exist enough backward compatibility problems with point releases, it would make sense that software publishers would want to avoid point releases (at least from a marketing perspective), when the release is backward compatible, e.g. Releases for former point releases, Service Packs for aggregated patches and the like. Has the single point (vs. double point) release come to mean that backward compatibility has been broken. If so, should it be avoided from a marketing perspective when backward compatibility still exists?