Nevis Update and Release Process
This document describes the Nevis Access App update procedure. It outlines the process as well as the intended delivery schedule of the respective artifacts in relation to external changes such as:
- New Android and iOS OS versions
- New OS SDK versions (mainly in regard to Xcode)
- Artifact bugfix releases
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:
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 priority changes lead to updates being planned and released in the overall Nevis release cycle (four releases a year).
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
|Security Fix||Security relevant fixes are addressed with high priority. They are released immediately after resolution.|
|iOS OS Update||iOS updates require compatibility. In case of lacking compatibility, the app might be taken out of the app store.|
|iOS Xcode Update||Xcode updates ensure continued capability of publishing into the app store and staying compatible with iOS.|
|Bugfix||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||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||Android SDK updates are usually not forced upon the developers and end users. Therefore, update pressure is low.|
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):
- An external or internal event triggers the update procedure.
- The update is planned and executed according to its priority.
- 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.
- After being informed about the update, the partner updates the customer's app store publication with the newest Access App version.
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:
- 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,
1is the patch version and
456is 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.