Release Notes for Sencha Cmd 5.0.1

Date: August 5, 2014
Version Number: 5.0.1.231
Windows - Mac OS X - Linux/64 - Linux/32

New Features

Bugs Fixed

Known Issues

Release Notes for Sencha Cmd 5.0.0

Date: May 29, 2014
Version Number: 5.0.0.160
Windows - Mac OS X - Linux/64 - Linux/32

New Features

Bugs Fixed

Release Notes for Sencha Cmd 5.0.0 Beta

Date: April 1, 2014
Version Number: 5.0.0.116
Windows - Mac OS X - Linux/64 - Linux/32

New Features

Bugs Fixed

Release Notes for Sencha Cmd 4.0.4

Date: April 2, 2014
Version Number: 4.0.4.84
Windows - Mac OS X - Linux/64 - Linux/32

Bugs Fixed

Release Notes for Sencha Cmd 4.0.3

Date: February 11, 2014
Version Number: 4.0.3.74
Windows - Mac OS X - Linux/64 - Linux/32

Bugs Fixed

Release Notes for Sencha Cmd 4.0.2

Date: December 20, 2013
Version Number: 4.0.2.67
Windows - Mac OS X - Linux/64 - Linux/32

New Features

Bugs Fixed

Known Issues

Release Notes for Sencha Cmd 4.0.1

Date: November 7, 2013
Version Number: 4.0.1.45
Windows - Mac OS X - Linux/64 - Linux/32

New Features

Bugs Fixed

Release Notes for Sencha Cmd 4.0.0

Date: September 24, 2013
Version Number: 4.0.0.203
Windows - Mac OS X - Linux/64 - Linux/32

New Features

Bugs Fixed

Release Notes for Sencha Cmd 4.0.0 RC

Date: September 9, 2013
Version Number: 4.0.0.161
Windows - Mac OS X - Linux/64 - Linux/32

Build Process

One of the major updates in this beta is the unification and consolidation of the build scripts used for generated applications. In previous releases of Sencha Cmd, applications had distinct and somewhat different build scripts based on the framework and version in use. This made it difficult at times to account for the differences in build process (for example, when upgrading frameworks or switching between apps for different frameworks).

Build Scripts

The .sencha/app/build-impl.xml file contains the root of the generated build script (as it always has for a Sencha Cmd generated app). This file, however, has been refactored into several smaller scripts. This makes understanding the build process much simpler compared to the single, large XML file in previous releases.

NOTE: While you do not need to read these scripts in order to build your application, skimming through them can be very helpful to understand how you can tune the build process to better suit your needs.

New Build Steps

The build script is basically a sequence of build steps called "targets". New to this set of targets are refresh and resolve.

refresh

The sencha app refresh command now routes to the new refresh target and this target is automatically invoked by the build. This means you no longer need to run sencha app refresh and sencha app build to get your app ready for "dev mode". In other words, sencha app refresh is just a subset of a full build and you can run that command if all you need to do is update metadata such as loader paths or class aliases.

resolve

A new feature of the build process is the ability to include a dynamic dependency resolution step (called resolve) that uses a headless WebKit (PhantomJS) to load your application and extract the dynamic loader's history. This is in essence the method used by SDK Tools v2 to determine dependencies and can help if your application does not fully declare its dependencies using requires and/or uses statements.

This extra build step (unlike all of the other build steps) is disabled by default because it adds several seconds to the build time. To enable this build step, add the following to .sencha/app/build.properties:

skip.resolve=0

CAUTION: If your application dynamically loads classes based on the browser/platform this method will not necessarily produce a build that will have the classes you need.

Build Properties

The properties for the build are much more completely listed and documented in .sencha/app/defaults.properties. You can override these in .sencha/app/build.properties or, depending on build environment, .sencha/app/production.properties or .sencha/app/testing.properties.

Use of JSON Files

Both applications and packages have controlling JSON definition files: app.json and package.json respectively. In this release, the properties of these files are imported into builds using "dot" notation. For example, you can set the app's theme in app.json as shown below:

{
    "theme": "ext-theme-neptune"
}

The above is equivalent to using .sencha/app/sencha.cfg and adding:

app.theme=ext-theme-neptune

Any properties set in both locations will have the value defined in the JSON file.

Property expansion has also been enabled for app.json properties, so the following style of property reference is now supported:

{
    "js": [{
        "path": "${framework.dir}/sencha-touch.js"
    },{
        "path": "${app.dir}/app.js"
    }]
}

Build Environment

One key change in the set of build properties in this release is the concept of "build environment" such as "production" or "testing". This is now controlled by the build.environment property. In the past this as an argument from the command-line and was passed in as args.environment but this was not always being set.

Build Folder

The new build.environment property is now used to formulate the default build directory as follows:

build.dir=${workspace.dir}/${build.environment}/${app.name}

This only applies to newly generated applications but is a better strategy by default than previous releases because it can more closely preserve the relative path between applications. In other words, the old structure of the build folder was:

build/
    App1/
        production/
            index.html
        testing/
            index.html
    App2/
        production/
            index.html
        testing/
            index.html

The new structure (again just the default) is:

build/
    production/
        App1/
            index.html
        App2/
            index.html
    testing/
        App1/
            index.html
        App2/
            index.html

It is trivial to have your own build folder structure by setting build.dir to be whatever you desire.

New Features

Bugs Fixed

Release Notes for Sencha Cmd 4.0.0 Beta 1

Date: July 18, 2013
Version Number: 4.0.0.126
Windows - Mac OS X - Linux/64 - Linux/32

With this release we have done considerable internal refactoring to support the the latest Sencha Touch beta as well as add Cordova integration and the new sencha app watch command.

Using the following command:

  sencha app watch

Your app build will run and then Cmd then will pause waiting for any changes you might make. When changes are detected only the minimum amount of work necessary is performed to bring your app and its CSS up to date, saving you from having to manually run sencha app refresh or rebuilding your Sass.

NOTE: This command requires Java 7. All other features of Cmd continue to work with Java 6.

New Features

Bugs Fixed

Release Notes for Sencha Cmd 3.1.2

Date: May 15, 2013
Version Number: 3.1.2.342
Windows - Mac OS X - Linux/64 - Linux/32

Noteworthy

This maintenance release contains improvements and fixes for many issues reported by our friend in the community. Many issues relate to the whole sencha app upgrade process, the meaning of "merge conflicts" and cases where Cmd did not handle those conflicts cleanly.

Framework Packages

Packages were introduced in Sencha Cmd 3.1.0. In that release, there was only one location for packages and that was set by workspace.package.dir to be ${workspace.dir}/packages. This meant that Ext JS 4.2's (many) packages would be copied to that folder.

In this release, frameworks can now contain their packages and these are no longer copied out of the framework when the framework is introduced to the workspace.

This detail was handled by Sencha Cmd, so this applies to Ext JS 4.2.0 as well as Ext JS 4.2.1. This is handled during framework upgrade and Sencha Cmd will remove the framework's packages from the workspace.packages.dir.

Upgrades

The general method for upgrading an application is sencha app upgrade and while that remains true in this release, you now have more control over the process. If you have multiple applications in a workspace, for example, you need to decouple the framework and application upgrades. By default, sencha app upgrade now operates as if you specified sencha app upgrade --noframework and proceeds to upgrade the current application to the current framework. This presupposes that you have already upgraded the framework as part of a upgrading a different application in the workspace.

If you have created packages, you can upgrade them like so from the package folder: 

sencha package upgrade

NOTE: If you are not upgrading frameworks, you may have to manually delete the "ext-*" packages from the "packages" folder and the "ext" folder as well. Then run the following to copy the framework and packages to the workspace: 

sencha -sdk /path/to/extjs generate workspace .

app.js

The majority of upgrade issues revolved around the "app.js" file. In previous releases, Sencha Cmd would add entries to "app.js" during code generation calls like sencha generate model (but also for controllers and the rest). Further, the location of this file differed by framework.

Due to the complications this approach creates and the fact that often these updates are not wanted on the application, these commands no longer update"app.js". You will need to add the newly created controllers, views, stores, etc. to the appropriate class. In many cases this will be on one of your controllers and not your application.

To make applications consistent across frameworks, and compatible-by-default with Sencha Architect, "app.js" now resides in the root folder of generated applications. The sencha app upgrade command will move this file from the "app" folder for Ext JS applications.

Merge Conflicts

With Sencha Cmd 3.0, we introduced tracking of generated code to allow upgrades to reconcile changes you may have made with changes to the "standard" flavor of certain key files. This is tracked in ".sencha/app/codegen.json". When generating code, if there is a file in the way, Cmd will use this data to do a 3-way merge with the version Cmd originally produced as the base, the version in the way as "Custom" and the new version as "Generated". In the case of overlapping changes, Cmd will report s "MERGE CONFLICT" in the log and write the standard (at least to many source control systems) conflict indicators in the file: 

<<<<<<< Generated
// change to Cmd generated content
=======
// changes you have made
>>>>>>> Custom

In this release we have fixed several cases where merge conflicts were falsely reported during sencha app upgrade (which regenerates certain core files like "app.js") and cases where subsequent steps of the upgrade would wrongly try to use a file containing merge conflicts.

There are two strategies for handling merge conflicts:

The use of source control to review the resulting changes from an upgrade is not new. The best practice here (as always) is to perform upgrades with a clean working tree (no pending changes). This will allow you to discard or revert whatever you need.

Using a Third-party Merge Tool

New in this release is the ability to configure an external merge tool to be called during the upgrade process. You can do this in a personal configuration file in your HOME directory. For example: 

C:\Users\Me>md .sencha
C:\Users\Me>cd .sencha
C:\Users\Me\.sencha>md cmd
C:\Users\Me\.sencha>cd cmd
C:\Users\Me\.sencha\cmd>notepad sencha.cfg

For example, you add these entries like those below to use the Perforce Visual Merge tool: 

cmd.merge.tool=C:\\Program Files\\Perforce\\p4merge.exe
cmd.merge.tool.args=${cmd.merge.tool.args.p4merge}

For further details, consult the comments in the "sencha.cfg" file in your install folder of Sencha Cmd. The support for personal Sencha Cmd configuration files is also documented in that same file.

New Features

Bugs Fixed

Known Issues

Release Notes for Sencha Cmd 3.1.1

Date: April 5, 2013
Version Number: 3.1.1.274
Windows - Mac OS X - Linux/64 - Linux/32

New Features

Bugs Fixed

Release Notes for Sencha Cmd 3.1.1 Beta 1

Date: March 28, 2013
Version Number: 3.1.1.270
Windows - Mac OS X - Linux/64 - Linux/32

New Features

Bugs Fixed

Release Notes for Sencha Cmd 3.1.0

Date: March 21, 2013
Version Number: 3.1.0.256
Windows - Mac OS X - Linux/64 - Linux/32

Bugs Fixed

Release Notes for Sencha Cmd 3.1.0 RC2

Date: March 14, 2013
Version Number: 3.1.0.239
Windows - Mac OS X - Linux/64 - Linux/32

New Features

Bugs Fixed

Release Notes for Sencha Cmd 3.1.0 RC

Date: February 27, 2013
Version Number: 3.1.0.192
Windows - Mac OS X - Linux/64 - Linux/32

New Features

Bugs Fixed

Release Notes for Sencha Cmd 3.1.0 Beta

Date: February 13, 2013
Version Number: 3.1.0.130

Ext JS: This version of Sencha Cmd 3.1 is not compatible with Ext JS 4.1.x but this will be corrected in the next release. For this release, only Ext JS 4.2.0.488 is supported.

Sencha Touch: This version of Sencha Cmd 3.1 is compatible with Sencha Touch 2.1+ however the new optimizer and package features (discussed below) are not yet supported for Sencha Touch applications.

Class Optimizer

This release of Sencha Cmd introduces the optimize command on the Compiler. The initial optimization provided is to rewrite class declarations into a more optimal form. This is beneficial because compiled code avoid many run-time checks and process things synchronously (vs. asynchronously as with the Sencha class system). This results is significantly fewer function calls and memory allocation required to load the JavaScript code of the framework and application.

Packages

The biggest new feature of Sencha Cmd 3.1 is that of packages. These are in many ways similar to applications from a build perspective. Like applications, packages contain:

Packages come in three basic flavors: theme, code and locale. All package types can contain any of the above assets. They primarily differ in how applications use them. For theme and locale packages, only one of each can be active during a given build. An application may require multiple theme and locale packages, but only one will be activated for a build based on build properties. The defaults are stored in your .sencha/app/sencha.cfg file and these can be specified on the command line to override the default.

Packages live at the top of the application/workspace in a "./packages" folder. That is, package "foo" is stored in "./packages/foo". In this release, only Ext JS 4.2 applications or other packages can use packages. In order to use a package, an application "requires" it in its app.json file: 

{
    "name": "foo",
    "type": "code",
    "version": "1.0.0",
    "compatVersion": "1.0.0",
    "requires": [{
        "name": "bar",
        "version": "1.1.0"
    }]
}

Packages can require other packages in their "package.json" file in the same way. Guides describing all of the particulars of packages will be available soon.

New Features

Bugs Fixed

Release Notes for Sencha Cmd 3.0.2

Date: December 26, 2012
Version Number: 3.0.2.288

Bugs Fixed

Total: 1

Release Notes for Sencha Cmd 3.0.1

Date: December 23, 2012
Version Number: 3.0.2.285

Bugs Fixed

Release Notes for Sencha Cmd 3.0.0 (GA)

Release Date: November 6, 2012
Version Number: 3.0.0.250

Bugs Fixed

Release Notes for Sencha Cmd 3.0.0 RC1

Release Date: October 25, 2012
Version Number: 3.0.0.230

Highlights

The highlights are improved UTF-8/multi-charset handling and correcting the overwriting issues with "sencha app upgrade". To use the new charset directive in your JS files, place this as the first line:

    //@charset ISO-8859-1

Instead of "ISO-8859-1", the value to the right of charset can be any valid Java charset name. The default is "UTF-8".

The charset directive is used to describe the encoding of an input file to the compiler. This does not effect the encoding of the output file. The content of the input file is converted to Unicode internally.

Also, auto-dependency detection has been improved so there should be fewer cases where you need "requires" or "uses" for the compiler and not the dev environment (due to synchronous loading).

Bugs Fixed

Release Notes for Sencha Cmd 3.0.0 Beta 3

Release Date: October 5, 2012
Version Number: 3.0.0.190

Bugs Fixed

Release Notes for Sencha Cmd 3.0.0 Beta 2

Release Date: September 26, 2012
Version Number: 3.0.0.181

Customizable Builds

In this release we have introduced a new, top-level build script to provide a consistent and customizable build process for Ext JS and Sencha Touch applications The "sencha app build" is one way to perform an application build. This now calls in to an Ant script to perform the actual build. This means the build can now be customized as needed.

The Ant equivalent of "sencha app build [production|testing|native|package]" is:

    sencha ant [production|testing|native|package] build
If you have Ant in your PATH, you can use it directly: 
    ant [production|testing|native|package] build

This runs the generated Ant build script to build your application. The reason the arguments are swapped vs "sencha app build" is to accommodate how Ant processes the command line.

That's all that is necessary to use the Ant script. You don't have to do anything extra to get Ant (it is provided by Sencha Cmd) and you don't have to know anything about Ant. That is, unless you want to customize the build script.

For details on tuning your application's Ant build script, start by reading the comments contained in "build.xml" (the Ant build script). Also you can consult the Ant Manual for details on using Ant.

Alternatively, you can chose to wrap your own build process around the "sencha app build" command.

Bugs Fixed