Maintaining

Roadmapping

The project roadmap is formally defined by GitHub milestones associated with the primary Warewulf repository.
The roadmap, and its milestones, are drafted and managed by the TSC chair to reflect and codify the priorities of the TSC and the community. Definition of the roadmap includes, but is not limited to
- the name, description, and due date for each milestone;
- the issues and PRs associated with a given milestone.
Only the TSC chair may assign issues to or remove issues from milestones. The TSC chair has proactive discretion to assign or move issues to reflect and codify the priorities of the TSC and the community, but may not act in opposition to the direction of the TSC.
Requests for changes to the roadmap that are made in the Warewulf community meeting are recorded in the Warewulf community journal.

All new contributions to the project should first be merged through a PR to the main branch.
Patches to a minor branch should be copied ("cherry-picked") from a previously-merged PR.
Each PR must, prior to merge, be reviewed and approved by a committer other than the author of the PR.
Before approving of a PR, an approver must confirm that
- all lint checks and tests pass with the given PR;
- new tests to cover the change have been added as appropriate;
- all commits in the PR have an appropriate DCO “Signed-Off-By”;
- documentation, including (but not necessarily limited to) the CHANGELOG and user guide, have been updated appropriately.
Any committer may, at his discretion, merge a PR that has the requisite approvals and for which all tests are passing. This includes, but is not limited to, a reviewer of the PR or the author of the PR.
Committers should consider the current roadmap when choosing to approve or merge a given PR. For example, proper and successful bugfixes are likely always appropriate to merge. However, new features may not be appropriate to merge if they are not included in the next milestone. New features which incompatibly alter existing interfaces or behavior should not be approved or merged unless included in the current milestone.
Committers which approve or merge PRs which are disruptive to the current milestone may have their committer access revoked by the TSC.

Warewulf releases follow a MAJOR.MINOR.PATCH format.
Releases are generated by an automated process encoded as a GitHub actions workflow.
All releases must pass the full Warewulf test suite.
Releases are published by a member of the TSC at the direction of the TSC.
Each release is accompanied by an updated changelog.

A minor release is denoted by a tag named v4.MINOR.0.
A minor release candidate is denoted by a tag named v4.MINOR.0rcNUMBER, where NUMBER begins at “1” and increments for each candidate for the given minor release.
Minor releases are defined by a previously-planned milestone named for the projected release.
A minor release candidate may be published by the TSC when all functional issues and pull requests in the associated milestone are closed. (e.g., documentation issues and pull requests may remain.) This may also be accomplished by the TSC re-scoping the associated milestone (e.g., by moving issues or pull requests to a different milestone).
A minor release may be published by the TSC two weeks after a release candidate if no major defects have been found in the release candidate and there are no open issues or pull requests.

A patch release is denoted by a tax named v4.MINOR.PATCH where PATCH is greater than 0, and tags a commit on a minor branch.
The TSC may identify changes in the “main” branch to be ported to a minor branch.
A patch release may be published by the TSC whenever one or more changes have been ported to a minor branch.