Skip to content
This repository has been archived by the owner on Sep 5, 2020. It is now read-only.

Branches and Versioning

Infernio edited this page Sep 20, 2019 · 1 revision

Types of Releases

CBash has two types of releases: major releases and maintenance releases (also called minor releases).

  • Major releases may break the API and can therefore require code changes. They are generally targeted at the Wrye Bash version that will be developed after the current one.
  • Maintenance releases, meanwhile, should never break the API. They are generally targeted at the Wrye Bash version that is currently being developed. They are developed on a separate branch, and get fixes backported from the major release (see below).

The exception to this rule is if the new Wrye Bash version gets released and development on the next one begins, but the new CBash version is not yet finished. In that case, the major release targets the currently developed Wrye Bash version, while the maintenance version simply falls away. Once the new CBash version is finished, the versions regain their regular meanings.

Versioning

CBash versions are split into three parts, raw.major.minor:

  • raw - incremented in case of severe breaking changes. Existing users of the DLL will almost definitely have to change their code. For example, 0.7.0 should have been 1.0.0, as it renamed every function in the DLL.
  • major - incremented when targeting a new Wrye Bash version. May break API, so existing users of the DLL may have to change their code. Examples would be the addition of a new required parameter, the deletion of a function, etc.
  • minor - incremented whenever the changes backported to a maintenance release have become significant enough (in the maintainer's eyes) to warrant a new release. May introduce features, but will mostly consist of bugfixes. Existing users of the DLL should not have to change their code - if backwards compatibility does break, it should be fixed in the next maintenance release.

Branches

  • dev is a stable branch, working towards the next major release.
  • nightly is an unstable branch, for testing out new features / changes / fixes before they are merged into dev.
  • mnt-x.y (short for 'maintenance') is a stable branch, working towards the next maintenance release for the major release x.y - in other words, the minor release x.y.z. For example, mnt-0.7 worked towards 0.7.1, 0.7.2, etc.
  • mnt-x.y-nightly is an unstable branch, for testing out backports before they are merged into mnt-x.y.

Merging / Fast-Forwarding

In short: follow the same rules as for the regular wrye-bash repo. no-ff merge large / important merges, ff-only or cherry-pick single commits or a short sequence of trivial ones. Note that the maintenance branches will likely never a no-ff merge since they consist of nothing but backports.

Example:

During Wrye Bash 307 development, dev worked towards the next major CBash version, 0.7.0, until that was finished (in b5fc54f). That commit was tagged as v0.7.0 and a new release created. After that, dev began working towards 0.8.0, while the new branch mnt-0.7 began working towards 0.7.1. Whenever fixes landed in dev, they were backported to mnt-0.7, and once enough backports had accrued on mnt-0.7, the most recent commit there was tagged as v0.7.x and a new release created. Once 0.8.0 was finished, the cycle began again.