ThinkGeo Cloud
ThinkGeo UI Controls
ThinkGeo Open Source
Help and Support
External Resources
ThinkGeo Cloud
ThinkGeo UI Controls
ThinkGeo Open Source
Help and Support
External Resources
Map suite provides a solid release cycle and version strategy for its GIS products. You can be assured of timely releases, dependable version numbers, and compatibility.
We issue a major update to our Map Suite GIS software products once annually, in the month of May. Each annual update increments the major version number by 1.0 – for example, Map Suite 6.0 in May 2012, Map Suite 7.0 in May 2013, and so on. Every major release of Map Suite's GIS software can be installed side-by-side with previous versions. This way, you can work on GIS projects that are based on different versions of Map Suite (e.g., Map Suite 4.0 and 5.0) at the same time.
Map Suite assembles are also backwards compatible for runtime. For example, if you previously purchased a Web Edition Production Server License and deployed it on a machine, next year's new version can also be deployed on that machine without any issues. There is an exception if you use strong naming and those details are described below.
In addition to the annual Map Suite update, we are continually building new features and enhancements into the products throughout the year. You can test, use and even deploy applications based on these upcoming features by downloading a Map Suite daily build; however, please note that features introduced between annual updates are considered beta, have not undergone full regression testing and may be in a state of continual evolution until the next annual release. Read more about the daily builds in the next section.
File versions will change every day as we continually revise and improve our GIS software products. Public daily builds are split between two branches: The “Bug” branch, which includes bug fixes only, increments the fourth digit in the version number (5.0.0.x). The “Development” branch, which includes both bug fixes and new features, increments the third digit (5.0.x.0). The “x” will increase by one each day.
You can download any of the bug or development daily build versions by accessing the Customer Portal. For instructions on getting the builds and or information see the Map Suite Daily Builds Guide.
In previous releases of our map controls, all of the Map Suite assemblies were strong-named and shared the same assembly version: 3.0.0.0. This was done to avoid breaking your GIS projects whenever we updated Map Suite with new features and bug fixes.
Many of our customers (particularly those who need to redistribute Map Suite assemblies via the GAC) reported that they prefer us to bind our assemblies with a specific EXE/DLL. In such a situation, if we update an existing Map Suite assembly, an exception is expected to remind you that there is a version mismatch and that you will need rebuild your project to make it work. This makes it easier to use the GAC and be sure of what version your GIS application will use.
In an attempt to meet both of these requirements we include both strong-named assemblies (with the assembly version updated as above) and weak-named assemblies in each Map Suite product package. This gives you the freedom to work whichever way you prefer.
We suggest that if you do not use the GAC that you use the weak named version of the assemblies. This will give you the most flexibility when updating the map control assemblies in the future.
We try and keep compatibility with the oldest version of the .NET framework possible. Having said that, it does present a challenge as new programming techniques are introduced that require us to rely on newer versions of the framework. In one recent case it was the INotifyPropertyChanged which was requested by more and more customers who use MVVM and heavy data binding that required us to reference the 3.0 Framework.
Our official stance is that we will keep compatibility with one framework version prior to the current one. For example, if the current .NET framework version is 4.0, we will only reference features supported up to and including the 3.5 framework. In most cases we stay even further behind than that if possible. We have to allow ourselves some flexibility to try and balance all of our customers' expectations. There are occasional exceptions, such as in the case where we have a new product and it requires features from the latest framework. In such a case, the product's requirements would be noted on the pre-sales product page of our website.
We see API compatibility as a key concept across all of our products. We strive to ensure that each new version of the API is compatible with previous versions. Having said that, no framework is perfect and occasionally a bad API is released that we want to correct in a future version. Our approach is to mark that API as obsolete and provide guidance relating to a new API. To date we have not actually removed any obsolete APIs; however, we reserve the right to remove them after one year of being marked obsolete. This equates into one full annual release cycle. For example, An API marked obsolete in version 6.0 during May of 2012 may be removed in version 7.0 during May of 2013. As I mentioned earlier we have never done this to date, but at some point we may need to due to a buildup of obsolete APIs that may mislead developers into choosing the wrong API during initial development.