98 lines
3.5 KiB
Markdown
98 lines
3.5 KiB
Markdown
|
# Zonemaster - Change management
|
||
|
|
|
||
|
|
## Scope
|
||
|
|
|
||
|
|
This document outlines how the any changes to the software during the
|
||
|
|
technical maintenance period will be classified and the process to implement
|
||
|
|
these changes.
|
||
|
|
|
||
|
|
## Input for change
|
||
|
|
|
||
|
|
Change requests can come from anywhere such as the users mailinglist, the
|
||
|
|
steering committee or the development team. The change requests could be
|
||
|
|
classified into two broad categories:
|
||
|
|
|
||
|
|
1. Minor change
|
||
|
|
2. Major change
|
||
|
|
|
||
|
|
## Minor change
|
||
|
|
|
||
|
|
The nature of minor change requests are explained in the following
|
||
|
|
subsection:
|
||
|
|
|
||
|
|
### Bug Fixing
|
||
|
|
|
||
|
|
Any bug fixes, the team or any user discovers should be published in the
|
||
|
|
GitHub issue tracker.
|
||
|
|
|
||
|
|
Not all issues in the tracker are bugs, and not all reported bugs are
|
||
|
|
software bugs, but can be protocol errors in DNS, or user or documentation
|
||
|
|
errors.
|
||
|
|
|
||
|
|
Bug fixes are included in minor releases. See the [version numbering policy]
|
||
|
|
document for documentation on version numbers for releases.
|
||
|
|
|
||
|
|
### Minor Changes
|
||
|
|
|
||
|
|
Minor changes are new features, changes or deprecated functionality that
|
||
|
|
do not break backwards compatibility, neither force any user to change or
|
||
|
|
update their environment that currently runs the software.
|
||
|
|
|
||
|
|
Minor changes are included in minor releases. See the [version numbering policy]
|
||
|
|
document for documentation on version numbers for releases.
|
||
|
|
|
||
|
|
## Major changes
|
||
|
|
|
||
|
|
Any change and specification that requires changes in the software
|
||
|
|
architecture, an API change or new major features could be classified
|
||
|
|
under the category "Major change".
|
||
|
|
|
||
|
|
Major changes are included in major releases. See the [version numbering policy]
|
||
|
|
document for documentation on version numbers for releases.
|
||
|
|
|
||
|
|
## Process to implement the change
|
||
|
|
|
||
|
|
Change requests can come from anywhere such as the users mailinglist, the
|
||
|
|
steering committee or the development team.
|
||
|
|
|
||
|
|
### Minor changes
|
||
|
|
|
||
|
|
A "bug fix" or "minor change" should be added as an issue in GitHub. Then
|
||
|
|
the person corresponding is assigned by the release manager or the person
|
||
|
|
who has created the issue. The assigned person should then close the
|
||
|
|
ticket within a specified time as mentioned in the "Key Performance
|
||
|
|
Indicator" (or) update the bug with the time duration on when the bug/minor improvement could be solved (or) comments the reason for not able to solve
|
||
|
|
the bug/minor improvement.
|
||
|
|
|
||
|
|
### Major changes
|
||
|
|
|
||
|
|
Any new development for Zonemaster must follow the strict process where
|
||
|
|
there are formal requirements, specifications for implementing the
|
||
|
|
requirements and then any design and architecture fulfilling the
|
||
|
|
specifications, and finally the implementation and quality assurance.
|
||
|
|
When all this is performed successfully the software package is released
|
||
|
|
using the release process.
|
||
|
|
|
||
|
|
#### Decision on discarding or including changes
|
||
|
|
|
||
|
|
Whatever be the type of change request, it should go through the "Issues
|
||
|
|
tracker" in the GitHub project. All requests should be promptly responded
|
||
|
|
to, even if the decision to acknowledge the request is postponed (or)
|
||
|
|
not taken into consideration.
|
||
|
|
|
||
|
|
Requirements should then be ranked in importance depending on a number of
|
||
|
|
factors such as complexity, amount of work, risk, architectural changes,
|
||
|
|
relevance to the product and so on.
|
||
|
|
|
||
|
|
The decision to include the requirement for the release during the
|
||
|
|
maintenance period will be taken by the development team in consultation
|
||
|
|
with the steering committee.
|
||
|
|
|
||
|
|
New requirements that are acknowledged (by the development team and the
|
||
|
|
steering committee) make it to the roadmap and planned for specification
|
||
|
|
and implementation. They are also added to the current set of requirements.
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
[version numbering policy]: ../design/Versions%20and%20Releases.md
|