Indistinguishable from line-noise.

CSPR.NG Blog

CMS Airship Version 1.2.0 Released

The official release has been tagged and signed. This new release adds a few new cool features and fixes some annoying bugs.

But first, let's talk about the current development plan and what version 1.2.0 means for Airship.

Beyond Airship 1.2.0

From here on out, we should have at least one minor release per quarter. The next one, version 1.3.0, is scheduled for October 1, 2016. The following one should be 1.4.0 on January 1, 2017. (We will have unscheduled minor releases if need be.)

After 1.3.0 is out, however, we're going to begin working on features for version 2.0.0, which will require PHP 7.1 and make extensive use of new language features. After our October 1 release, the master branch will be for version 2.0.0 development, and the v1.x branch will carry us from 1.3.0 to 1.4.0.

We'd like to release a new major version every year, on January 1, and a new minor release every quarter (at minimum) with new features, for each of the maintained branches.

As documented, the v1.x branch will no longer be maintained after June 26, 2019 (three years after v1.0.0 was released). By the time version 1.x is retired, version 4 should be out (which will presumably require PHP 7.3, assuming there's no major version bump between now and then). Our choice in a three year cycle is to keep up with PHP's release and end-of-support cycle.

After all, why go through all the trouble to build a self-updating web application just to encourage people to leave it out-of-date forever?

So that's roughly the plan, going forward. Outside adding features to v1.3.0, Paragon Initiative Enterprises will be building Gadgets, Motifs, and Cabins (some for demonstration purposes; others for actual use). There will be announcements at the PIE blog in due time.

Changes in Version 1.2.0

#57:
Our Database class can now connect to UNIX sockets. Set the hostname to
unix:/path/to/socket.

#65:
You can now add database connections to the local database connection pool.
You can also add database connection pools for app-specific purposes.
In the future, we'll support more than just PostgreSQL.

Database connections are now lazy instead of eager, which should result in
less overhead on HTTP requests that don't use additional databases. (In our
cabins, this affects nothing.)