...
Adonis Web Recruitment, Adonis Replicator, Adonis Timeclock, and Adonis Plugins may have different number 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 the a customer's 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 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
...
An Early Access Release is interim builds 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 features that are incomplete or 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.
Resource planning
...
analyze available development resources
...
plan amount of working days
...
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
...
.
...
forecasting the " hands-on -keyboard" time of the developers within the release
Release Numbering
Format The format of the release numbering is as follows:
yyyy.rd.pp
yyyy= the year the development started
rd: Release = 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, patch 1 Number one is the main release, 2 and two or higher are patches containing corrections.
...
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