Program Versions and long-term stable releases

What Does This Mean To Me?

As always, our goal at MCS Software is to provide customers with the best software and support available. Two competing factors in meeting this goal have always been trying to add new features and customizations, and trying to keep our product stable and bug free.. If we add features for one customer, we might accidentally break something else for another customer. This creates a tension between customers who are happy with the way things are and customers who need new features to help the special ways they operate. Effective August 2010, MCS Software will release new features in a separate branch of each product while maintaining the previous long-term stable branch for customers who do not need new features until they have been proven in production. You can choose to use the latest-and-greatest branch (the release cycle we have historically employed); or, you can opt to use only the new long-term stable branch if you want to hold off on new features until they have been proven in the field for a few months.

Changes To Program Versioning

At any given time, a program will now have either one or two maintained branches. By maintained, we mean that we will fix bugs in that branch if any are found. There will always be a long-term stable branch that will not get any new features. When new features are added, there will also be a latest-and-greatest branch. Once the latestand-greatest branch has been proven to be stable, it will be become the long-term stable branch and the previous long-term stable branch will no longer be maintained. We may also from time to time produce a beta, experimental, or private build. These builds include changes that we have been unable to test as well as we like and will be working closely with a particular customer to monitor the changes before making them public for other customers.

To help customers make sense of all of this, we are going to be assigning version numbers in a special way to help identify what kind of release a particular version is. The three basic release types are shown in the following list:

Latest-and-Greatest

Identified by having odd numbers in the second position. Version numbers x.1.x.0, x.3.x.0, etc are latest-and-greatest branch releases.

Long-Term Stable

Identified by an even minor version number. Versions x.0.x.0, x.2.x.0, x.4.x.0, etc are considered long-term stable branch releases.

Which branch should I choose?

If you need our newest features or customizations, then you need to get the latest-and-greatest branch. If you like getting new features more frequently and staying on the cutting edge of technology, you are encouraged to take the latest-and-greatest branch. If however you need to test new features in a lab before deploying, you might consider sticking with the long-term stable branch, knowing that if you find bugs we can fix them for you without having to give you even more new features to test.

When do I have to decide? Can I change my mind later?

Every time you upgrade, you can choose whether to stick with the long-term stable or the latest-and-greatest. Many customers will choose the long-term stable branch until they see a feature available in the latest-and-greatest branch that would benefit them, and then upgrade. You can move from the long-term stable up to the latest-and-greatest at any time. Since you cannot downgrade versions after database upgrades have been made, once you deploy a release from the latest-and-greatest branch, you will have to stay on it until the next long-term stable branch is released.

Is the Latest-and-Greatest considered unstable or Beta software?

No. The latest-and-greatest is not unstable or beta. It is production-ready. However, it is not as customer proven as the long-term stable version, so it is expected that there will be less bugs in the long-term stable version.

Will every bug found be fixed in the long-term stable branch?

No. There are occasionally bugs that require significant changes to the system in order to fix them. If fixing the bug requires changing large amounts of code which require significant amounts of retesting and the impact of the bug is limited, we may choose to only fix these types of bugs in the latest-and-greatest branch. We may also promote the latest-and-greatest branch to be the new long-term stable branch if this happens.