Date: September 24, 2013
Version Number: 4.0.0.203
Windows -
Mac OS X -
Linux/64 -
Linux/32
Date: September 9, 2013
Version Number: 4.0.0.161
Windows -
Mac OS X -
Linux/64 -
Linux/32
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).
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.
The build script is basically a sequence of build steps called "targets". New to this set of targets are refresh and resolve.
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.
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.
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.
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" }] }
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.
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.
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.
Date: May 15, 2013
Version Number: 3.1.2.342
Windows -
Mac OS X -
Linux/64 -
Linux/32
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.
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.
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 .
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.
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.
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.
Date: April 5, 2013
Version Number: 3.1.1.274
Windows -
Mac OS X -
Linux/64 -
Linux/32
Date: March 28, 2013
Version Number: 3.1.1.270
Windows -
Mac OS X -
Linux/64 -
Linux/32
Date: March 21, 2013
Version Number: 3.1.0.256
Windows -
Mac OS X -
Linux/64 -
Linux/32
Date: March 14, 2013
Version Number: 3.1.0.239
Windows -
Mac OS X -
Linux/64 -
Linux/32
Date: February 27, 2013
Version Number: 3.1.0.192
Windows -
Mac OS X -
Linux/64 -
Linux/32
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.
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.
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.
Date: December 26, 2012
Version Number: 3.0.2.288
Date: December 23, 2012
Version Number: 3.0.2.285
Release Date: November 6, 2012
Version Number: 3.0.0.250
Release Date: October 25, 2012
Version Number: 3.0.0.230
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).
Release Date: October 5, 2012
Version Number: 3.0.0.190
Release Date: September 26, 2012
Version Number: 3.0.0.181
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] buildIf 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.