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: 4.80.2.1
Major: Represents a technology layer. This can be .NET or Visual Studio versions or other technology changes that break compatibility.
Minor: Represents the core IFS Applications track the tool version is intended for.
Build: "Binary patch" number for periodically published service releases. Note: Stable releases uses even numbers while development releases uses odd numbers.
Revision: For stable releases the revision number is increased when there is a need to publish a hot-fix release in between normal releases.
This happens if a correction for a severity 1 or 2 issue needs to be
released immediately. For development releases any number of revision releases may be
published between two stable releases.
Example: 4.80.6.0 (stable), 4.80.6.1, 4.80.6.2 (Hotfixes), 4.80.8.0 (stable)
All releases versioned for a specific core track is fully backwards compatible. This means that when developing IFS Applications 8 functionality, any 4.80.* 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 minor version number and create a new archive branch.
Clarification: 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 the recommendation to use the latest available version of Application Forms Development Tools for the current base track.
A stable release is a release that contains new features or bug corrections, is well tested and published on an official release archive. Planed stable releases will be made available periodically when there is content to be published. 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. For stable releases the build number is always even.
It is always recommended to work with stable releases 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. For development releases the build number is always odd.
Example 4.80.3.* are all development releases published between stable release 4.80.2.0 and 4.80.4.0.
A developer should normally only work with a development release if the reason for doing so is clear and that he or she is well aware of possible implications.
The main official archives for stable releases of F1 tools is \\Corpnet\Files\F1Tools . Development releases will be published on \\Corpnet\Files\F1Tools_Beta\IFSApplicationFormsDevelopment . For Application Forms development tools this translates to \\Corpnet\Files\F1Tools\IFSApplicationFormsDevelopment.
When a developer opens a project, the tool automatically looks for newer versions in the release archives and notifies the developer about later available versions. In this situation the developer is given the choice to update to the later version. 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. The information about current and available versions are always available in the Development Tools About dialog. It is possible to manually update to a later version from this dialog.
The notification and about dialog is by default not presenting any information about development releases. The intention is to minimize confusion for the normal developer that is expected to work only with stable releases. Development release information can be enabled by following these steps.
How to enable development releases:
In some cases it is needed to setup archives in other locations than \\Corpnet\Files . This could be on partner sites or in IFS offices that for some reason don't have a DFS synchronization of corpnet files. In these cases one would probably also change where the tools search for new releases.
How to change release archive references: