If you’re familiar with the software history of Latitude Geographics, you’ll know that we used be a Java shop. Now, we still use Java for our ArcIMS generation products, while we’ve adopted .NET for our ArcGIS Server Generation products.
In contrast to Java, Microsoft .NET has a very explicit versioning scheme. From MSDN:
“Each assembly has a version number as part of its identity. As such, two assemblies that differ by version number are considered by the runtime to be completely different assemblies. This version number is physically represented as a four-part string with the following format:
…”
http://msdn.microsoft.com/en-us/library/51ket42z(VS.71).aspx
When we build our .NET products, we want our assembly versions to reflect the released product version, and vice-versa.
Most of the software industry is in agreement on the use of the first two digits of a software version (major and minor). Incrementing the major version is typically reserved for releases containing major new features, rewrites, new technologies or paradigms. Incrementing the minor version signifies a release containing new features. There is some discrepancy in the industry; however, over the use of the build and revision numbers. Indeed, our staff has had differing views on how to use these numbers as well.
At the release of Geocortex Essentials 2.0, we’ve decided to change our perspective on this so it’s worth mention.
Pre-2.0
Prior to 2.0, a build number increment could include new feature development. That is to say that 1.3 and 1.3.1 both introduced new features; however, 1.3 was probably more significant than 1.3.1 with regards to the features it introduced. A “Hotfix” typically embodied a release containing bug fixes only (e.g., 1.4 Hotfix 1). It is worth mention that revision number is automatically generated, and typically reflects the number of physical builds created on our build server since the increment of a build, minor, or major version number (i.e., we “zero” the revision number when incrementing any other version number).
We also introduced “Service Packs” when we felt that the changes didn’t warrant a version upgrade (e.g., 1.5.2 SP1). This was not a decision based on a “rule”. I’ve always been dissatisfied with this somewhat ad-hoc approach to versioning, so following 2.0 we’ve decided to be a bit more procedural.
2.0 and Beyond
As with prior to 2.0 the major and minor version number will be reserved for major product architectural or conceptual changes, and the revision number will reflect the number of physical builds created on our build server. The main difference is the way in which we will treat the minor and build numbers. Going forward, we will increment the minor version any time that a release introduces new features. We will increment the build number to signify a release which contains bug fixes. A few examples will help clarify.
| 2.0.0.745 |
Major release, includes architectural changes and introduces the Geocortex Essentials REST Elements. |
| 2.0.1.792 |
Build release (or “dot” release), contains bug fixes only. |
| 2.1.0.XXX |
Minor release, will include new features. |
| 2.1.1.XXX |
Dot release, contains bug fixes only. |
| 2.2.0.XXX |
Minor release, new features. |
| 3.0.0.XXX |
Major release will include architectural changes, and/or introduce new technologies or paradigms. |
It is worth mentioning that a goal we have in the near future is to better support version upgrades of our Geocortex Essentials software. If we can distribute “dot releases” frequently without causing our customers the hassle of migrations during upgrades, we are better equipped to provide faster turn-around times between defect detection and resolution.
With a month into the fall conference season, September has already brought the Latitude team to a wide number of conferences worldwide, including (but not limited to!) the Intergeo event in Germany, the GITA Oil and Gas conference in Houston, the Hawaii/Pacific GIS event in Honolulu and a number of ESRI Canada events across this great, big land. I find myself sitting in the part of our office where its easy to detect the travellers: droopy plants, the blinking voicemail light and large stacks of mail crowding out desks…
