We are changing how we release software

Date: 4/11/2019

To: All Fischer Customers

We’ve changed how we release software, this is important for you to understand so please review…

We now have a new approach to releases and patching in general. As many of you know, we have been working towards continuous integration for some time and we are now closer than ever to reaching this goal. As a result, Fischer International will no longer issue service packs. Instead, we have collapsed our build process and changed our release model and versioning methodology.

The model will now be as follows:

We are adopting a model consisting of three numbers as: MAJOR.MINOR.PATCH

MAJOR: Will be incremented based on a business decision, if the release is considered large, it will be incremented. In major releases you can expect innovative new features that were not present in previous releases. We will designate major changes and the introduction of new features or larger enhancements to existing features as reason to flip the MAJOR bit to the next number.

MINOR: When new features are added to the product, the minor bit will be incremented. This will be decided internally when to designate a release as MINOR. This may include new features that are on a smaller scale, but also any smaller tweaks to existing features as well.

PATCH: Any defect requiring a fix will trigger increment this value.

This is motivated by multiple factors:

From a development standpoint, it does not make sense for us to maintain a separate code-base for patching when our upgrade code-base does the same [technical] job when it is actually applied to an instance of our software. Removing this redundancy will allow Fischer to streamline our release process and decrease the amount of time between releases.

As a software company it is important for our customers to understand each time there is a service pack, it deviates from our main code branch. For example: if we are up to service pack 10, 11, etc for a given release, this creates a massive duplication of effort and retrofitting of fixes into multiple versions which can become a time consuming and resource intensive process as the code and fix itself may need to be altered as a result of other changes that have come from previous service packs. This can slow down release cycles and handcuff Fischer from getting you fixes and/or access to the latest and greatest features we’ve built.

I felt it important to explain all of that because the result of our previous delivery model is a symptom of some of the upgrade issues you have all experienced in the past. Moving to the new versioning model will decrease the internal efforts by both our Development and Quality Assurance / Control processes and result in less issues at release time and less workarounds and nuances that need to be coded into service packs.

The benefit is an agile, continuous integration delivery model. While we will NOT automatically patch your solution (the current process of notification and logistics will remain until we make further progress on our CI efforts) I am very excited that we have arrived at this milestone as it will result in a smoother maintenance process and faster access to our newest features for you, our valued customers.

If you have any questions or concerns, please feel free to reach out to me directly. This policy is officially in place as of this email and we will operate in this fashion beginning with your next scheduled maintenance window.