Nevis Update and Release Process

Introduction

The overall goal of the update and release process is to ensure that our customers are release-capable at any point in time.

External Changes and Priorities for new Access App Releases

Some external changes trigger the process for updating and shipping new Access App versions. The priority of a change indicates how fast and with which internal priority external changes are handled:

Priorities

• LOW

  Low priority changes lead to updates being planned but not directly scheduled in the normal app development life cycle. They are scheduled "around" important features and updates. The release itself occurs in the overall Nevis release cycle (four releases a year).

• MEDIUM

  Medium priority changes lead to updates being planned and released in the overall Nevis release cycle (four releases a year).

• HIGH

  High priority changes lead to updates being planned and scheduled as soon as the depending change is available. The release is published as soon as it is available.

Triggers and Priorities

External Change	Priority	Description
Security Fix	HIGH	Security relevant fixes are addressed with high priority. They are released immediately after resolution.
iOS OS Update	HIGH	iOS updates require compatibility. In case of lacking compatibility, the app might be taken out of the app store.
iOS Xcode Update	HIGH	Xcode updates ensure continued capability of publishing into the app store and staying compatible with iOS.
Bugfix	MEDIUM	Bugs detected in the Nevis implementation are addressed with medium priority. This usually aligns fixes with the next planned Nevis release according to the release cycle.
Android OS Update	MEDIUM	As Android OS updates take weeks or months to be rolled out to the latest Android devices, the update pressure is lower than with the iOS platform.
Android SDK Update	LOW	Android SDK updates are usually not forced upon the developers and end users. Therefore, update pressure is low.

Update Process

The next figure shows the update process of the Access App:

The update process includes the following steps (the step numbers correspond with the numbers in the above figure):

1. An external or internal event triggers the update procedure.
2. The update is planned and executed according to its priority.
3. If the update is complete, all Access App instances are rebuilt based on the changes, and published to a SendSafely app delivery workspace shared with the partner or customer. A notification email is sent to a predefined list of recipients once a new version of an app is available. The list of notification recipients is defined during the initial ordering of the first Access App.
4. After being informed about the update, the partner updates the customer's app store publication with the newest Access App version.

Versioning

Access App Versioning

The Access App follows a "semantic-like" versioning system. This means that we use major, minor, and patch versions to identify changes to the software, for example: 3.2.10456.

• Major Version: An increase in the major version indicates a change in core behavior or the implementation of a new feature involving many operations.
• Minor Version: The minor version increases only in case of minor changes.
• Patch Version: The patch version is calculated using the formula patch version * 10000 + build number. For example, 10456 means 1 is the patch version and 456 is the build number.

Using this versioning system allows us to easily communicate the level of change in each release of the Access App. We hope this information is helpful to our users in understanding the updates and improvements in each version.