EntitySpaces Version Numbers Explained

With the old EntitySpaces ("ES") version numbering scheme, last used for the 1.5.3 release, there was no way to tell how old it was, or whether it contained breaking changes. The goal of the current numbering scheme is to bring some clarity to those issues, while still taking advantage of the assembly versioning built in to .NET.

.NET - <major version>.<minor version>.<build number>.<revision>
ES   -      YYYY              #             MMDD           #

Using EntitySpaces Developer Release 2007.1.1210.0 as an example:

• Major - 2007 - A change to the major version number indicates significant new features, some bug fixes, and a higher likely hood of breaking changes.
• Minor - 1 - A change to the minor version indicates important new features, some bug fixes, and a possibility of breaking changes.
• Build - 1210 - Released December 10th. A change to the build number indicates new features and/or bug fixes, with no known breaking changes.
• Revision - 0 - Changes to the revision are reserved for quick patches, in case something gets broken between builds, and does not get caught before release by our extensive in-house testing, or during the Beta phase.

Admittedly, using the year for the major version, is to conform to current marketing conventions, as much as anything else. So, it is possible that a Beta for ES2009 would be released in late 2008. Or, that a patch to ES2008 could be released in early 2009. In either case, the minor version would be incremented, so that one is always guaranteed that a higher complete version number means a more recent product version, even though the build number (MMDD) may drop for the new year.

Breaking Changes

As developers who use our own product, we understand the need to keep breaking changes to a minimum. However, as with most products, breaking changes are sometimes a necessary evil. In order to properly introduce a new feature, we cannot box ourselves into 100% backwards compatibility.

We document all potentially breaking changes in our Release Notes, with a bold "breaking" notice for that feature. We say "potentially" because whether, or not, your code gets broken depends on the options used for generation, the methods used in your code, and whether you are using C# or VB.NET. One of our goals, when we introduce a breaking change, is to have the compiler catch it. We do not want it hidden away to produce runtime errors. Ideally, a global search and replace would fix most of them. When trying to evaluate the cost/benefit of an upgrade, the Release Notes are an invaluable tool at your disposal. In them, we even try to estimate the impact of fixing the change based on our own experience, e.g., "minor". Using IE or FF Edit -> Find on this page, and searching for "breaking", should take you right to them.

Release Notes and Betas

When we issue a new release, whether it is a production release ("Release"), or a Beta, we post details of the enhancements and fixes on our main site's Support -> Release Notes menu. The release notes for production releases contain cumulative changes for any intermediate Betas. That means, if you skip one, or more, production releases, you do not need to read all the Beta Release Notes to get caught up.

You should read the Release Notes for the release you are installing (or upgrading to). They contain installation instructions, and instructions for upgrading from prior releases. For upgrades, you should, also, read the Release Notes for each intervening production release, for those you have skipped. They not only contain a list of enhancements and fixes, but usage notes and examples for the enhancements, and highlight any potentially breaking changes.