Новости и события

We often get asked about the software development process and release cycle we use for Deswik.Suite. It’s been developed and refined over a number of years but is broadly based on two main principles – being responsive to our customers’ needs and providing a quality product.

Key points to note about our development process and release cycle are as follows:

1. Our development methodology could best be described as Agile but with a somewhat longer release cycle.
2. We release a new version approximately every three to four months.
   • There is no real concept of major or minor versions though we still use the old style version numbering system for historical reasons. All versions, regardless of their given release number, contain a roughly equal amount of new functionality. For example, our most current stable version is 5.0. At the beginning of September we will release version 5.1 but it will be no different to 5.0 in terms of the amount of change in functionality, stability or architecture.
   • Our releases are time driven not functionality driven. We have taken this approach to provide new functionality to our users as quickly as possible. If a planned feature for a certain release is not ready in time for the planned release date, the feature will be pushed into the next release and delivered three to four months later, rather than affecting the release date of the planned version.
   • This approach ensures we are delivering new functionality to our clients as quickly as possible.

3. We release patches (for bug fixes) to our last four most recent releases every week.
   • There are always patches for the most recently released version.
   • Patches for the other two prior releases are only provided if requested by customers for specific issues they are having and they do not have the ability to update to the latest version.
   • Again, this approach has been taken with our customers in mind to ensure that any bug fixes that may be relevant to them are made available as quickly as possible.
   • These patches rarely, if ever, contain new functionality.
   • These patches will not make changes to file formats, so patches for a specific version are always forward and backward compatible.

4. Our testing regimes are varied — from unit tests, regression tests, right through to end-to-end user testing on real projects by our consultants.
   • There’s always room for improvement but our software is widely known in the industry to be significantly more stable than that of our competitors.
   • Just because we release patches more frequently than our competitors does not mean there are more bugs in our software – it simply means we are more responsive and customer focussed.

And finally a note about patching:

• It’s fairly easy for our users to get hooked on updating to the latest patch available but it’s usually not required. Our codebase is huge and the twenty to thirty odd fixes released in each patch are unlikely to affect most users.
• We encourage users and their IT department to review the release notes associated with each patch to see if their particular issue has been addressed in that patch. The support ticket numbers are shown against each fix in the release notes so you will be able to see if your issue has been fixed in a particular release. In any case, our support desk will let you know as soon as your particular issue has been addressed. If you find an issue in the release notes that you think may affect you but you didn’t raise it, please reach out to support@deswik.com to confirm its applicability to your situation.
• If there is a particularly critical bug that has been identified and/or fixed, a notification will be sent out to all customers alerting them of this and recommending installation of the applicable patch.

If you have any specific questions or concerns regarding our release strategy or patching methodology, please send us a note at support@deswik.com.