Author:	        Steve Landers <[email protected]>
Author:         Jan Nijtmans <[email protected]>
State:          Draft
Type:           Process

---

Abstract

This TIP proposes a new development workflow to align Tcl and Tk development with modern "feature branch” practices to keep the trunk stable and to make it easier to review, test and manage changes before they are merged. In this workflow all development will take place on branches created from the trunk, with each change reviewed by at least one TCT member before being merged back into the trunk.

Rationale

While all contributions to improving the Tcl and Tk core are encouraged and appreciated, not every change is universally accepted. If an inappropriate change is made directly to the Tcl or Tk trunks it will need to be reverted. Additionally, if a single commit contains both acceptable and unacceptable changes, extra effort is required to separate them and remove only the unapproved modifications. And on occasion some changes have been known to break the trunk.

This TIP attempts to address this situation in two ways - by the adoption of a feature branch development workflow and by introducing the requirement of a TCT member (not the change author) to review the changes.

Guidelines

The new guidelines can be stated as a series of points:

• All development (new features, changes and bug fixes - even trivial fixes like typo's) must be done in a branch derived from trunk.
• Each branch should be a feature branch, in that it should only contain a single change in functionality or a single bug fix.
• Before merging to trunk at least one TCT member (other than the author) must have reviewed the branch and approved merging.
• Bug fixes can be merged after review but new features or functional changes will require a TIP before merging.
• The TCT member review should address code quality and (if there is a TIP) whether the implementation and TIP are consistent.
• formatting changes (e.g. indentation or whitespace changes) should not be mixed with functional changes.
• The review should ensure that these guidelines are met.
• During a release process only the release manager (currently Don Porter) is allowed to cherry-pick changes from trunk to lower branches.
• When no release is underway bug-fixes can be back-ported after there has been at least one successful trunk build on GitHub.

When the release process starts, an "rc0" tag (followed by "rc1", "rc2" ...) is put on the branch being released, that's how the state of the release process can be recognised. The release process ends when the "core-?-?-?" tag is present.

Practical considerations

This workflow has the advantage that release candidate branches will no longer be needed - e.g. core-9-1-branch would itself be the rc branch when a new release is being prepared. This is similar to what is done in the SQLite release process.

Will having a TCT member review the change be a burden? Perhaps but based on recent experience it may actually reduce the overhead in adopting new features. And it will hopefully leave the trunk in a more pristine state which will make it easier for others to test. Should the review load become too great then consideration could be given to expanding the TCT membership.

Copyright

This document has been placed in the public domain.