Today we are happy to announce general availability of Xsemble release 2.4 — build 2.4.0 to be precise. Xsemble 2.4 is an important milestone. As Xsemble grows in functionality, release 2.4 serves as the bridge between the old and the new. Many important changes have gone into the internal model, and those changes are more interesting and powerful than the feature enhancements.

We recommend all projects using the previous version to move to 2.4 soon — to get on to the new paradigms that are included. Migration is easy, and covered below.

Feature Enhancements

Here we cover a few major feature enhancements that have gone into 2.4.0.

Progress Report, Kanban Chart

We gave a boost to the Progress Report functionality. Since Xsemble breaks down the job of developing a larger software application into that of developing smaller components, the Work Breakdown Structure (WBS) can be realized in terms of these components. From the statuses and sizes of the components, you can get a very crisp status. Shown below is the summary view.

As one can see, the status is available both in terms of the component count and component sizes.

The new Kanban chart gives a useful view to understand the status visually.

The detailed view which lets you filter components based on certain criteria existed prior to 2.4, and hence is not covered here.

Enhanced Health Check

Health Check is important for validating the design automatically. The Health Check in Assembler’s Workbench was revamped completely. It now does a better job by catching more issues. Here is a screenshot of the enhanced Health Checker.

Internal Changes

The internal model has changed on multiple fronts. Here are the major ones:

  1. There is formalization of the server and the browser platform where the code runs. Named layers can be based on these platforms, and the project nodes work in these layers. The layers play an important role in the interconnections among these nodes.
  2. There is a new technology model that works underneath. It formally identifies and defines Platform technologies and Connection technologies.
  3. Previously, multiple finish nodes were allowed in a project. They are consolidated into a single finish node for simplicity.
  4. The project setting to define whether it is a top level project, and if not to set its hierarchy, is now removed. This gives one flexibility to use any project as a subproject in another project. This paves the way for creating reusable projects to be included in various larger projects.
  5. The jump links that used to go to an arbitrary entry point within the project hierarchy are not supported any more.

This improved model supports more types of connections than were possible before.

Migration to 2.4

Special effort has gone into keeping backward compatibility, and making the migration easy.

When one opens a repository or a project that is compatible with 2.3, it automatically adjusts its internal structures in memory — including creating a single finish node out of multiple finish node. When you save it, the changes get written to the file system. For most projects, this simple opening and saving will be enough measure for their migration.

Projects that used jump links will be the only ones which will require small changes in the structure to route the connections through the Finish node. We are willing to help any such projects migrate.

Get Started

To get started with version 2.4, go to and click on the “Get Started” button. It comes with documentation that is necessary to onboard one. Contact if you have any questions.

[Illustration glass image credit: Image by Noupload from Pixabay]