Date: May 5, 2015
Version Number: 5.1.3.61
Windows -
Mac OS X -
Linux/64 -
Linux/32
Date: January 27, 2015
Version Number: 5.1.2.52
Windows -
Mac OS X -
Linux/64 -
Linux/32
Date: January 5, 2015
Version Number: 5.1.1.39
Windows -
Mac OS X -
Linux/64 -
Linux/32
Date: December 10, 2014
Version Number: 5.1.0.26
Windows -
Mac OS X -
Linux/64 -
Linux/32
Date: November 22, 2014
Version Number: 5.1.0.13
Windows -
Mac OS X -
Linux/64 -
Linux/32
Date: October 16, 2014
Version Number: 5.0.3.324
Windows -
Mac OS X -
Linux/64 -
Linux/32
If your html/markup file is located in a folder other than the app's root folder (where app.json resides), the relative paths for dev mode, generated into bootstrap.json, are now going to pick up your changes to indexHtmlPath (see SDKTOOLS-960). With this fix the previous workaround based on editing the "bootstrap" object in app.json is no longer needed. If you have changed the "bootstrap" properties to fix this issue, you should revert to the default which is:
"bootstrap": { "base": "${app.dir}", "manifest": "bootstrap.json", "microloader": "bootstrap.js", "css": "bootstrap.css" },
You will also most likely need to deal with the framework's appFolder config. In you Ext.app.Application-derived class and in your call to Ext.application you will need to specify the correct relative path for appFolder. This is a framework limitation since the loader path for your application in the bootstrap data is being replaced by that config property.
Date: September 9, 2014
Version Number: 5.0.2.270
Windows -
Mac OS X -
Linux/64 -
Linux/32
The fix for SDKTOOLS-898 (see below) means that packages with extra content in their package.json file built by this version of Sencha Cmd will not be usable by older versions of Sencha Cmd. This is because the extra content is included in the package "signature" hash but is not by older versions. This is only an issue if the package.json file contains properties that older versions of Sencha Cmd did not expect.
Date: August 5, 2014
Version Number: 5.0.1.231
Windows -
Mac OS X -
Linux/64 -
Linux/32
Date: May 29, 2014
Version Number: 5.0.0.160
Windows -
Mac OS X -
Linux/64 -
Linux/32
Date: April 1, 2014
Version Number: 5.0.0.116
Windows -
Mac OS X -
Linux/64 -
Linux/32
Date: April 2, 2014
Version Number: 4.0.4.84
Windows -
Mac OS X -
Linux/64 -
Linux/32
Date: February 11, 2014
Version Number: 4.0.3.74
Windows -
Mac OS X -
Linux/64 -
Linux/32
Date: December 20, 2013
Version Number: 4.0.2.67
Windows -
Mac OS X -
Linux/64 -
Linux/32
Date: November 7, 2013
Version Number: 4.0.1.45
Windows -
Mac OS X -
Linux/64 -
Linux/32
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.