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