Contributing

Contributing to fenix-framework

We use https://github.com/nvie/gitflow as a branching model for our repository.

Key Branches

• master release versions
• develop next release version
• maint/X.Y maintenance branches for previously released versions

Pull Requests

• Pull requests should be submitted against branch develop

Coding Standards

• TODO

Versioning Scheme

We use the Semantic Versioning Specification, with regard to the Framework's public API.

In this scheme, the Framework's versions take the form X.Y.Z, where X is the Major version, Y is the Minor version, and Z is the patch version. Each element increases numerically in increments of one. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

The rules regarding which element to increment are as follows:

• Major: Public API disruption (backward incompatible changes)
• Minor: New functionality additions to the public API (backward compatible), or marking public API as deprecated (to be removed in a future Major release)
• Patch: Bug Fixes, internal changes fixing incorrect behavior

Pre-release versions are given a version in the form X.Y.Z-rcW, where X.Y.Z denotes the intended version for this pre-release, and W denotes the number of the pre-release. (Multiple Pre-Releases of the same version must be sequentially named, for instance: 2.1.0-rc1 -> 2.1.0-rc2 -> 2.1.0.

(Special thanks to http://semver.org/, from which much of the text of this section was adapted)

Internal API Versioning

The Semantic Versioning Specification only mentions the Public API. However, a similar scheme is applicable for internal API, as follows:

• Internal API changes (be it addition or removal of API in for instance, the BackEnd interface, or the CodeGenerator) spanning multiple areas (Either affecting multiple Backends or the Core) are implemented in a Minor Version.
• Internal Changes in a particular Backend/Module are implemented in a Patch version, as long as the change has no effect outside the module.