The How and Why

of Axiom Stack

Contents

Overview

This overview details our process for releasing software. Not only do we launch products, but we release new versions. In this document we detail the pieces that go into each launch and version. We explain our testing, clarify our version numbers and describe the standards we are committed to when we develop software.

Teh Codez

When creating software you should always adhere to some accepted practices. This will keep the code quality up. Also, we'd like to have some standards for API reasons. We would like for you to adopt our software. Thus, the following are how we will maintain the code:

  • Naming - Method names will be camel case. Also, we prefer being explicit about what a function does. Thus, we will use more words to describe functionality and less in the way of abbreviation. Maintaining code that is full of shorthand rarely helps anyone. Having had to maintain that kind of code, we don't wish it upon anyone.

Stability

We need to release stable software. Certainly bugs will arise in code. There are always edge cases and parts that could not be tested. However, we have worked to provide tests in a handful of ways.

Should our tests pass and you still find an issue, you can inform us through our discussion group or by shooting an email to support@axiomsoftwareinc.com. Or, should you feel ambitious, attack the issue on your own. Our source base for Axiom Stack is opened. Thus, you have the power to make the change.

Threading

The nature of our software requires manual testing. Testing multi-threaded applications is both a daunting and often inaccurate task. We want to be sure that we have done all that we can to flesh out issues before you use them. To test these threaded applications we use a tool provided by those guys at IBM called ConTest.

Javascript Testing

Because we use Axiom Stack as our primary application framework, we use JS for our server-side application logic. In order to test these applications, and provide you with a testing framework for your applications, we have taken jsUnit and extended it to fit our needs.

The great thing about this is that we can run tests for our applications as well as for the framework all within the same system. Our testing framework reports your information, successes or failures, in a JUnit format. This means that any system, like Bamboo that reports on your results can use this testing framework.

Continuous Integration

To make sure we maintain a level of quality, we regression test our software. To make it easier, we wrote a very small continuous integration tool which notifies us, quite loudly, of failures. The tool provides us with a simple analysis of the results of our tests.

Version Numbers

Our versions should mean something, and now they do. This being the case, we don't see any need to reinvent the wheel. The Linux folks, the smart people they are, figured our a version numbering system that has become pretty standard. Thus, we'll use the same concepts with a couple of slight tweaks.

Our versions will be in the form of A.B.C.D:

  • A - This constitutes an architectural change. Changing the internals of the system. If we decide to make some major modifications to the core of our software, we will increment this value. Keep in mind, this will not change often. This is likely to change when major architectural changes occur.
  • B - This is for major changes. Major here relates mainly to features and improvements. Because we rely heavily on other technologies, we like to try to stay as up-to-date as we can. Thus, we will upgrade the technology that drives our products. Also, we do have a few original ideas and would like to push those out to you as well. This would also include major changes to the user interface of certain products.
  • C - This is for minor changes. Mostly you'll see bugs and improvements to functionality fall here.
  • D - This is designates a patch/point release. That means, "whoops something slipped by" and we had to put something together to stabilize the software. Assuming the above testing works out, you shouldn't see much of this. But, it happens. Thus, we're letting you know about it.

Our Commitment

In an attempt to be consistent and to provide you with a stable environment to work in, we have a set of standards that we will adhere to. They are as follows:

  • Documentation - We would like to keep you informed of the actual functionality of our code. Because we have opened the source up to you for consumption it is important that you can decode the meaning of our madness. Plus, we recognize the difficulty of application development on a framework without help.
  • Deprecation - We recognize that we may, at some point, screw up an API. In an effort to make upgrading less of a chore we will deprecate functions that should not be used. Yet, we love to keep things clean and pare down unnecessary or invalid functionality. So, if we deprecate a function, you can assume that it will be around for at least three (3) major releases (see version numbers above). After that there is no guarantee that the method you are using will continue to exist. But, our theory is that by the point in time where three major releases have occurred, you'll likely be using the recommended method. The only case in which deprecation will not hold true is when there is an architectural change (see version numbers above).
  • Archives - While we will continue to produce changes within our software, we want you to be able to get at earlier versions. We certainly recommend upgrading, but for whatever reason you may need an older version. We will keep these around for you.
  • Community - We want to foster community and communication. It is how we will get better and how you can self-serve. In an attempt to foster this environment we've created a couple Google Groups (listed below). We want to provide easy access to you by any of our team members. Plus, sometimes it's just good to chat about technology. You might even catch a glimpse of the new features or products that are coming before the rest of the world does.
  • Issue Tracking - While bugs are surely a mystery to us, we understand how necessary it is for development. We use an issue tracking system called Jira. So, should you somehow stumble upon an issue within our products, you can plop it into our tracking system.
    • Community Involvement - If you have an alteration to a product we have built, or a plugin you'd like to see included, let us know. Drop a ticket into our tracking system and upload the patch. We'd love to take a look include the features that you come up with. We'll run them through our gauntlet of tests and evaluate the feature for inclusion. Who knows, someday you may be able to say "Yea...I contributed to _that_!"