This article describes the Application Forms Development Tools versioning, compatibility plan and release cycle.
All published assemblies in an Application Forms Development Tools release is versioned as follows.
Major.Minor.Build.Revision. Example: 90.452.1.12
Major: IFS Applications Version (90 - Applications 9)
Minor: .NET Version (2,4 etc) + .NET minor (0,5) + .NET Build (0, 1, 2). 452 is .NET 4.5.2
Build: "Binary patch" number for periodically published releases.
Revision: Build revision numbering for a given binary patch. Revision can also be updated for hot fixes to a published patch.
All releases versioned for a specific core track is fully backwards compatible. This means that when developing IFS Applications 9 functionality, any 90.452.* release of IFS Application Forms Development Tools can be used. In situations where compatibility can't be kept intact, then a new release track will be released with a new major or minor version number and create a new archive branch.
NB! Development Tools design runtime behavior. With "backwards compatible" means that a later version of the development tool will provide design time support for the functionality that the current runtime provides. It is not guaranteed that two versions of development tools will produce the exact same syntax. If there are differences, then they should be interchangeable for the given runtime though.
It is always recommended to use the latest available version of Application Forms Development Tools for the current base track; i.e.; update to the latest version whenever a new release is provided.
A stable release is a release that contains new features or bug corrections, is well tested and published on an official update center. The normal version increment will be build number indicating a periodically planed version, e.g. x.x.2.x. In between this schedule hot fix releases may have to be published for high severity issues. In this case the revision number of the version will be increased, e.g. x.x.2.1.
It is always recommended to work with the latest stable release, if there is not a good reason for not doing so. In other words: If you don't know of any reason not to use the latest stable release, that is what you should use.
A development release does not conform to the same quality standards as a stable release. The intention behind the publication can be for example giving a developer or group of developers access to new functionality or corrections in an early stage. There can be any number of development releases in between stable releases. API's and functionality may be added and removed between development releases and are not guaranteed to be included in a coming stable release.
Development releases are also published on the update center. Development releases are not visible and available for developers by default. One have to set an option to enable development releases.
How to enable updates and notifications for development releases:
IFS Development Tools update center is a web page or file share containing the different development tools supplied by the framework. From such an update center wanted tools can be installed and the installed tools will probe the update center for new releases. The main update center of F1 tools is \\Corpnet\Files\F1Tools\ . Application Forms Development Tools is located in <UC>\IFSApplicationFormsDevelopment\.
At the top of an update center the IFSF1ToolsInstaller.exe is found. This is an umbrella installer that can be used to install one or several of the F1 tools. This installer act as an umbrella and relay to the tool specific installers. For Application Forms Development Tools, IFSF1ToolsInstaller can be used to install the tools or the tools specific installer in .\IFSApplicationFormsDevelopment can be run directly.
NB! The tool specific installer SetupIFSAPFDevelopment90.exe is not required to be run from the UC. If there is a need to it is possible to run the installer executable from another location. The UC from where the setup is copied is compiled into the setup. So even if the setup is moved prior to running, the resulting development project structure will be tied to that UC.
When a developer creates or opens a project, the tool automatically probes for newer versions at the update center. If a newer version is published the developer is given the choice to update. The developer will be notified only once per later version. If the developer doesn't update at that time, he or she will not be notified again until next time a later version is published. Information about current and available versions are provided in the Development Tools About dialog. From here it is also possible to manually trigger an update to a later version.