Development Standards

Versioning

DHB's digital services and products and its other first-party packages follow Semantic Versioning. Major framework releases are released every year, while minor and patch releases may be released as often as every two weeks. Minor and patch releases should never contain breaking changes.

When referencing the DHB framework or its components from your application or package, you should always use a version constraint such as ^1.0, since major releases of DHB products do include breaking changes. However, we strive to always ensure you may update to a new major release in one day or less.

Release Calendar

These are the target dates for releases. These dates may vary slightly due to unforeseen circumstances.

Release type	Frequency	Months	Note
Major (e.g. 3)	6 monthly	Second Wednesdays of May and November
Minor (e.g. 3.x)	2 monthly	Second Wednesdays of July, September, November, March and May.
Patch (e.g. 3.x.x)	2 weekly	Wednesdays

Design Standards

note

The Design Standards and Web CI (Corporate Identity) will be available under a seperate domain and are currently work in progress.

Logos and Formats

For any type of logo the prefered filetype is SVG. Since this is an ongoing effort to transition all clubs, associations, etc. to this format, a master GitHub repository (dhbhockey/logos) has been created for version control. Contributions can be made via Pull Requests.

Coding Standards

PHP Coding style

DHB digital products follow the PSR-12 coding standard and the PSR-4 autoloading standard.

PHPDoc

Below is an example of a valid DHB documentation block.

/**
 * Documentation of the function.
 *
 * @param string             $someVar Description of the variable
 * @param \Namespaced\Object $someObj Description of the variable
 *
 * @return boolean
 *
 * @throws \Exception
 */
public function someFunction(string $someVar, \Namespaced\Object $someObj = null): bool
{
    //
    return true;
}

Version Control

All bug fixes should be sent to the latest version that supports bug fixes. Bug fixes should never be sent to the main branch unless they fix features that exist only in the upcoming release.

Minor features that are fully backward compatible with the current release may be sent to the latest stable branch.

Major new features or features with breaking changes should always be sent to the main branch, which contains the upcoming release.