Release types

Main Release​

• Main releases are used to introduce significant extensions to our products. ​

• For Adonis Personnel Manager and Adonis Personnel Portal we have 6 main releases per year ​

• Main Releases are planned every 2 months ​

• Each   main   release  has a  number   of   tickets   assigned   based   on   available   development   resources  and estimations ​

• Each release has a landing zone for the delivery, which is usually the second or the third week of  every two months. ​

• The  customers   receive  an email  notifications   when   main   release  is  ready  for  install . The email  notification   contains  the release notes so the customers could see what is included. ​

​

Adonis Web Recruitment, Adonis Replicator, Adonis Timeclock, Adonis Plugins may have different  number of releases per year as this is defined by the lower number of changes we have to address in  these products ​

Patch Release​

​Adonis Support create jira issues from the ConnectWise tickets reported by the customers ​

• Adonis Support prioritizes each of the issue as per low->medium->high->highest scale ​

• Each of the highest priority issues are reviewed on development meeting not later than 1  working day after creation ​

• Development board decides on the issue assignment for the patch or one of the main  releases based on the priority, work arounds availability, product road map and complexity ​

• Most critical bugs are assigned to a patch releases, evaluated and scheduled for the nearest  possible release date ​

• Patches are only applied for the main releases ​

Development Release (Early Access Release)

Development releases are interim builds of an Adonis Application  that we make available so that  customers and implementation projects can try out and test new features, especially those features that are critical for rollouts and can't wait for the next official release. 

While we try to keep these development releases stable, they have not undergone the same degree of testing as a full release, and could contain features that are incomplete or may change or be removed before the next full release.

Limited upgrade path. Because development releases represent work in progress, we cannot provide a fully supported upgrade path. Once a main release is available the Development release will be obsolete the customer is advised to upgrade to the main release. 

Planning the release​

Resource planning ​

• analyze available development resources ​

• plan amount of working days ​

• check the holidays, days off, vacations, average sick leave days inside release period ​

• forecasting of repeating activities that are not actual development. Daily stand ups, releases planning  activities, 3rd line support, other projects involvement for developers assigned to the product release ​

• forecasting  the  " hands-on -keyboard" time  of   the   developers   within   the   release ​

Release scope ​

• Match hands-on-keyboard time to the total amount of time estimated by developers for the issues in release​

• Finalize the release scope to align available resources and estimations  based on issues priorities  ​
• Define the list of issues to be delivered within the release ​
• Assign issues that are not getting into current release to one of the  upcoming releases ​

Release Numbering ​

Format of the release numbering is as follows:  

yyyy.rrrd.pp

yyyy year the development started

rrrd: Release number 10 to 60, 6 releases per year, single digits are used for development releases.  x1 - x9   11,12,...19

pp: Patch number, patch 1 is the main release, 2 or higher are patches containing corrections. 

​Main Releases

2019.10, 2019.20 ... 2019.60  ​

Intermediate Releases:

2019.11, 2019.21 ... 2019.61, 2019.62 ​

​Patch  Releases:

2019.10.1.2 (Patch 1 for Release 2019.10.), 2019.20.1.6  (Patch 5 for release 2019.20) ​

Development Release:

2019.11.0.1 (Development Release)