Open Manage Church (OMC)

You are viewing the change log. If you need help please contact Anthony Master themaster5.07@gmail.com



VERSION START 1.0-beta
----------------------

A standard needed to be set to control version and change logging. Here is what will take effect starting immediately on 3/14/2013:

For reference here is an example version number: 1.7.2.3.5.14

* A major site-wide change will change the "major version" number
    + In the example this would be the "1"
    + An example of this would be user access rights
* A major functionality change will change the "minor version" number
    + In the example this would be the "7"
    + An example of this would be implementing custom reporting
* Adding/Removing/Expanding a section will increase the "sub version" number
    + In the example this would be the "2"
    + An example of this type of change would be a document section
	+ An example of Expansion would be adding data to an existing report
* A scripting enhancement of automation of an action will result in an "enhancement version" number
    + In the example this would be the "3"
    + An example of this would be completing courses upon status change from Med Detox
* A major bug fix will result in a "major bug fix version" number
    + In the example this would be the "5"
    + An example of this would be if a function was not functioning due to a coding error
* A minor bug fix or typo fix would result in a "minor fix version" number
    + In the example this would be the "14"
    + An example of this would be a change in the CSS or fixing a mispelling

Hence we have versions such as "major.minor.sub.enhancement.majorBugFix.minorFix"

The Following policies are also being implemented

1. Minor Fixes only require review before committing
2. Major Bug Fixes a thorough review of all the affected pages and sub-pages
3. An Enhancement requires a thorough review of the new section and a quick review to ensure functionality of the entire application
4. A Sub Version requires a thorough review of the new section and a quick review to ensure functionality of the entire application
5. A Minor Version requires an exhaustive review of the changed functionality and a thorough review of the entire application it also requires the change log be reviewed and compiled for all previous changes. The Minor Version Change must also be submitted on GitHub using a branch and merge method for easy reversal.
6. A Major Version requires an exhaustive review of the entire application and an update/upgrade to the server(s). The Major Version Change must also be submitted on GitHub using a branch method and reviewed by all IT Personnel before merging with the "master" branch

If a package(program) must be added to the server for the new change then the change is automatically promoted to a Major Version Change.

All changes must be tested thoroughly on the development server to ensure functionality and correctness before being submitted for approval to push to the live application.