Skip to end of banner
Go to start of banner

Adonis Release Management

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 17 Next »

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, 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​

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

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

  • Every bug request with the highest priority are 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 builds 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 features that are incomplete or may change or 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.

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.rd.pp

yyyy year the development started

rd: 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) ​

Early Access Release:

2019.11.0.1 (Development Release)

  • No labels