Release strategy ConnectPlaza

Introduction

Having a clear release strategy creates clarity for both customers and developers. It creates a clear picture of what happens when and where. Too often we see a that a customer driven release, i.e. a customer problem is solved as soon as possible, is released without a clear perspective about the wider implications. Often customer-related issues can be resolved with a workaround and therefore a quick release is not necessary.

This document describes the release strategy for ConnectPlaza.

The version number structure

Releases are marked with a version number. The structure of the version number is determined partly by the impact of a release.

The version number of our products and libraries consists of a major, a minor and a maintenance number. Those can be followed by a text such as SNAPSHOT RC1 or URL. Eg 2.2.0 or 2.1.3-SNAPSHOT

Each position in the version number indicates a certain degree of change in the version.

A product consists of multiple libraries combined into one product. Within a library, we provide software libraries in the form of a jar file with certain functionality. A library consists of only one file. A new version of a library in a product automatically creates a new version of the product.

Maintenance number

A maintenance number increment indicates that it is a minor amendment. It is an amendment in which no new versions of supporting third party libraries are used. A change in the maintenance number from a library covers bug fixes from the previous version of the library and must be backwards compatible with the current version of the product in which the library is used. The new version of the library, changes the maintenance number of the product. Because a library can be used in many other libraries, several private libraries can get new maintenance numbers.

Supporting third-party libraries are not modified.

When the maintenance number of a library is incremented, the current version of the library can be replaced by the new library.

A maintenance release number may be performed at any time. Maintenance releases are not scheduled in the release calendar.

Minor number

A minor increment indicates that there has been a change in functionality. This can be added functionality or modified functionality. It is also possible that there are new (minor) versions of third-party libraries that have been applied.

By amending the minor number there will also be changes to the minor number of the version of the product in which the library is used. A minor change in a library can not be directly used in the current version of the product. This is because there are (possibly) other third party libraries needed, which need to be replaced simultaneously.

In a minor release you may not change the environment in which the version is running. So no new Java version, database version etc.

A minor update is always scheduled according to a release calendar.

Major number

A major number increment indicates a big change in functionality and/or context. Like a new major version of third party library, a revised method of the software, e.g. the requirement of a higher version of Java used or database software.

In a major change, the context may change. With a major version change you can be asked to fully replace the software on your machine with the new installation of the software. A major update can be performed by the update mechanism if there are no context changes (so no newer java version).

A major update / upgrade is always scheduled according to a release calendar. It may be that the upgrade must be performed manually by a system administrator of the customer or a consultant of ConnectPlaza.

Update strategy

Maintenance release

With this release the update will consist of an update.zip file. A patch update contains only the modified version of a library. A patch can only be performed if the version of the product to which the patch is performed in the major and the minor number is equal to her version of the patch.

For example, running a 2.2.3 patch on a 2.1.0 version of the product, the product must first be upgraded to product version 2.2.0 and all previous patches (2.2.1 and 2.2.2 in this example).

Minor release

With the release of a minor update, there also will be an update.zip file, containing all changed libraries and configuration. The update removes all the libraries which are no longer necessary and / or replaces them with new versions. In addition, there can be additional configuration properties that may have been added and / or removed. The update mechanism ensures that configuration will be merged with the existing configuration, but never overwrites the existing configuration.

A minor release is fully implemented by the present update mechanism. There are no infrastructural changes to be made.

Major release

With a major release the update strategy will be done with an update file, but there can be infrastructural changes which must be applied by hand (or by your system administrators). It can also be an implementation of a totally new version of our software.
A major release is always announced to the customers. So they know when the upgrade will be carried out. The implications for a major upgrade will also be communicated to our customers in case of a context change.

Product Release Strategy

Maintenance

When fixing bugs we will check the urgency of the bug and whether the bug can be resolved without a change in context and/or third party libraries.

When the bug is causing a production failure and a solution without a change in context and/or third party libraries is needed to resolve the issue, a maintenance release or hotfix can be applied and the patch will be released for all customers, bypassing the release calendar.

Product Release Calendar

For the release of the next minor or major product release the release calendar is created. In this calendar you wil find the new features that will be incorporated and which bugs will be fixed.
Changes in environmental context and / or changes to releases of key third-party libraries will be done in a major release. All other changes are a minor release.

Release Candidate

Once a minor or major release is ready, a Release Candidate will be build. The version number is followed by the letters RCx, where x is the number of the release candicate.

The release candidate is available to all internal testers of the product and will be applied to the internal test server. Also, all external beta testers can install the release candidate to their test environments. It is not intended that an RC version is installed on a production environment.

All reported errors are resolved as quick as possible in the RC after which a next RC. There is no new functionality build in throughout the RC phase. Errors in existing functionality will be fixed. New functionality will be added to the release calendar for a next release.

Once an RC version has been fully tested and upgraded the product's release will be the next step. An update.zip will be created and will be made available for the update mechanism. Customers can view the changelog for version via the documentation site at the following URL: https://www.connectplaza.com/doc/en/technical-guide/connectagent/release-notes.html.

Release cycle

We will try to have a bi-annual release cycle. These may be minor or major releases. The first Release Candidate will be built on the end date of the release calendar. During three months, the release candidate is tested internally and externally. After three months there will be an official release, provided the RC is accepted by Q&A.