Versioning

You might encounter some versioning issues when working on Flex applications. When compiling, you can choose the version of the SDK to use and you can target specific versions of Adobe® Flash® Player. You can replicate behavior of previous SDK versions. Also, you can design applications that can load modules and other SWF files that were compiled with different SDKs.

Overview of versioning

When a new version of Flex is released, it usually includes changes to the APIs and compiler. As a result, if you were working on a project but then upgraded your version of the SDK, you might have to refactor some part of your code to be compatible with the new version. In addition, if the audience for your application is restricted in which version of Flash Player it can use, you might have to make certain concessions to ensure that your application runs without errors.

Maintain older look and feel

The differences between some versions of Flex go beyond new features. The layout schemes and the styles of many components might have changed from one version to the next. If you want to use new Flex features but have your application look and feel the same as an older version of Flex, you can specify the version whose styles you want to use with the compatibility-version compiler option. For more information, see Backward compatibility.

Target specific Player versions

With current Flex tools, you can target your application toward a specific version of Flash Player. To do this, you use the target-player compiler option. This is not the same as targeting an application to a specific SWF version. For more information, see Targeting Flash Player versions.

Ensure sub-applications and applications work together

If you want to load a sub-application into a main application that was compiled with a different version of the compiler, you can use the loadForCompatibility property of the SWFLoader control. Setting this property ensures that each SWF file contains its own definitions of the linked classes, removing reliance on particular APIs that might have changed between versions. You can only use this property when the main application and sub-application were compiled with version 3.2 of the Flex framework or later. In addition, the main application must be compiled with a more recent or the same version of the compiler as the sub-applications. For more information, see Developing multi-versioned applications.

Backward compatibility

To specify the version of the Flex compiler and framework that the output should be compatible with, use the compatibility-version compiler option. Possible values for this compiler option are defined as constants in the FlexVersion class. This option affects some behavior such as the theme, layout rules, padding and gaps, skins, and other style settings. In addition, it affects the rules for parsing properties files.

If you do not explicitly set the value of the compatibility-version option, the compiler defaults to the current SDK's version.

For the command-line compilers, you can either pass the compatibility-version compiler option on the command line or set the value in the configuration file. The following example sets the compatibility version to 4.0 in the flex-config.xml file:

 <compiler> 
 	<mxml> 
 		<compatibility-version>4.0</compatibility-version> 
 	<mxml> 
 <compiler>

When you set the compatibility-version option, you must be sure that the configuration files that you use are compatible with the version you select.

You can programmatically access the version of the application that you are running by using the FlexVersion class. To get the current compatibility version in your application, use the compatibilityVersionString property of that class. This lets you conditionalize the logic in your application based on the compatibility version.

Using themes with compatibility-version

When you set the compatibility version, you should also be sure to use the appropriate theme file that matches that version. Themes are located in the frameworks/themes directory. For Flex 4.x, you do not have to specify a theme file. The default Spark theme file is designed for Flex 4.x compatibility. However, if you want the Flex 3 look and feel, you must specify the Halo theme or another theme that is compatible with the Flex 3 SDK.

The following command-line example uses the Halo theme and sets compatibility-version to 3.0.0:
mxmlc -compatibility-version=3.0.0 -theme=..\frameworks\themes\Halo\halo.swc MyApp.mxml

For more information on using themes, see About themes.

The default style sheets for several versions of Flex are available in the framework.swc file. This SWC file contains the current default style sheet (defaults.css) and the Flex 3 default style sheet (defaults-3.0.0.css). The compiler uses the style sheet that is appropriate for the compatibility version you set. For example, if you set the compatibility-version option to 3.0, then the compiler uses the Flex 3 default style sheet.

Differences between SDK 3 and SDK 4.x

The differences between SDK 3 and SDK 4.x that result from setting the compatibility-version option include fonts, skins, and styles.

If you set compatibility-version to 3.0.0, differences include:

  • The value of embedAsCFF defaults to false. This means that non-CFF fonts are embedded, rather than CFF fonts. For more information, see Embedding fonts with MX components.

  • The Halo theme should be used to define the look and feel of your application. This includes styles and skins.

  • Bi-directional binding will not work.

Targeting Flash Player versions

Use the target-player compiler option to specify the version of Flash Player that you want to target with the application. Features requiring a later version of Flash Player are not compiled into the application.

One reason for setting the target Player version is if you are unsure of Player usage penetration rates and want to choose a Player version that is lower than the most recent one. Another reason is if your users are locked in to a particular Player version, such as when they are on an intranet and cannot upgrade.

The target-player option has the following syntax:

 -target-player=major_version.minor_version.revision

The major_version is required while minor_version and revision are optional. If you do not specify the minor_version or revision, the compiler uses zero.

For Flex 4.0, the only supported value of the target-player option is 10.0.0. For Flex 4.1, the default value is 10.1.0. For Flex 4.5, the default value is 10.2.0. For Flex 4.6, the default value is 11.1.

The minimum value for Flex 4.6 is 11.1. The minimum value for Flex 4.5 is 10.2.0. For Flex 4.0 and 4.1, the minimum value is 10.0.0 (although Flex 4.1 included Player 10.1).

If you do not explicitly set the value of this option, the compiler uses the default from the flex-config.xml file.

SWF version (advanced)

The swf-version compiler option specifies the SWF file format version of the output SWF file. Features requiring a later version of the SWF file format are not compiled into the application. This is different from the Player version in that it refers to the SWF specification versioning scheme.

For example, to compile an application to version 10 of the SWF specification, use the following:
-swf-version=10

This is an advanced option that you should only use if you have an understanding of the SWF specification that you are targeting.

Navigation

Using Flex » Developer tools

Adobe and Adobe Flash Player are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries and are used by permission from Adobe. No other license to the Adobe trademarks are granted.