Release types

Main Release​

• The Main release includes significant extensions to the product. ​

• For the Adonis Personnel Manager and Adonis Personnel Portal, there are six main releases per year. ​ (one release every two months)

• Each main release has several change requests assigned based on available development resources and estimations. ​

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

• The customer receives an email notification when the release is published. The email notification contains detailed release notes.

​

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

Patch Release​

​A patch release contains bug requests that interrupt a customer's work or process flow. ​

• Adonis Help Desk prioritizes each of the issues using the following scale; low->medium->high->highest 

• Every bug request with the highest priority is reviewed by development not later than one working day after creation ​

• Based on factors like availability for work around's, product road map, and complexity, the product development team assign the issue to a patch or the version currently in development.​

• Patches are applied to the main release

​Early Access Release

An Early Access Release is interim build of an Adonis Application that we make available so that customers and implementation projects can try out and test new features, especially those 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 incomplete features, which may change or be removed before the next full release.
They have a limited upgrade path. Because development releases represent work in progress, we cannot provide a fully supported upgrade path. Once the main release is available, the Early Access Release is obsolete, and the customer needs to upgrade to the main release.

Release Numbering ​

The format of the release numbering is as follows:  

yyyy.rd.pp

yyyy= the year the development started

rd= the release number 10 to 60, 6 releases per year; single digits are used for development releases.  x1 - x9   11,12,...19

pp= Patch number, Number one is the main release, and two or higher are patches containing corrections. 

​Main Releases

2019.10, 2019.20 ... 2019.60  ​

Early Access Releases:

2019.11, 2019.21 ... 2019.61, 2019.62 ​

​Patch  Releases:

2019.10.2.1 (Patch 1 for Release 2019.10.), 2019.20.6.1  (Patch 5 for release 2019.20) ​

Early Access Release:

2019.11.0.1 (Development Release)

Release Planning

Content

Before every major release, development moves development requests from the Short Term Release queue to the backlog of the upcoming release. The priority and nature of the request determine the product release to which the issue is assigned.

All incoming modifications are vetted and assigned to the Short-Term Queue, meaning the request is assigned to one of the upcoming releases. The long-term Queue gathers all the interest requests, but no plans exist to assign them to release soon. Both queues are consulted for relevant requests when working on a major module makeover.

Resource planning ​

• analyze available development resources ​

• plan amount of working days ​

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

• forecasting of repeating activities that are not actual development. Daily stand-ups, release planning  activities, 3rd line support, and 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 time estimated by developers for the issues in a 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 the current release to one of the  upcoming releases ​

Release life span

The life span is six releases before the latest product version. During its life span, patches are available, fixing various critical errors. If the life span expires, the version is no longer maintained.