Release Process

The Redwax Project defines a release to be the same as that published by The Apache Software Foundation, and the release process is broadly similar.

Generically, a release is anything that is published beyond the group that owns it. For a Redwax project, that means any publication outside the development community, defined as individuals actively participating in development or following the dev list.

More narrowly, an official Redwax release is one which has been endorsed as an "act of the Redwax Project" by the Committers of a Redwax project.

Each proposed release is put to a vote by any member of the dev list. Anyone may vote, and votes cast by Committers are binding. For a release vote to pass, a minimum of three binding positive votes and more binding positive than binding negative votes MUST be cast. Releases may not be vetoed.

Before casting +1 binding positive votes, individuals are required to download all signed source code packages onto their own hardware, verify that they meet all requirements of Redwax policy on releases as described below, validate all cryptographic signatures, compile as provided, and test the result on their own platform.

Release votes SHOULD remain open sufficiently long to allow all committers to vote; regardless of their timezone, national-days, off or similar - and be open for at least 72 hours. Upon the first request of any committer - a single, automatic 24 hour extension can be added.

Redwax Projects shall publish official releases and shall not publish unreleased materials outside the development community.

During the process of developing software and preparing a release, various packages are made available to the development community for testing purposes. Redwax Projects must direct outsiders towards official releases rather than raw source repositories, nightly builds, snapshots, release candidates, or any other similar packages. The only people who are supposed to know about such developer resources are individuals actively participating in development or following the dev list and thus aware of the conditions placed on unreleased materials.

Every release must contain one or more source packages, which must be sufficient for a user to build and test the release provided they have access to the appropriate platform and tools.

All supplied packages must be cryptographically signed by the people casting binding votes with a detached signature.

All releases must be accompanied by a suitable Changelog, with changes related to security issues highlighted clearly within that Changelog.

The Redwax Project produces open source software. All releases are in the form of the source materials needed to make changes to the software being released.

As a convenience to users that might not have the appropriate tools to build a compiled version of the source, binary/bytecode packages may be distributed alongside official Redwax releases. In all such cases, the binary/bytecode package must have the same version number as the source release, must only add binary/bytecode files that are the result of compiling that version of the source code release and its dependencies, and be cryptographically signed by the committer that produced them.

Every release must be accompanied by a suitable Changelog, indicating changes made between the release and the previous release.

Security disclosures covered by the release need to be published prominently within the Changelog.

Once a release is approved, all artifacts must be uploaded to the project's subdirectory within the canonical Redwax distribution channel, https://redwax.eu/dist.

The Project Management Committe of a Redwax Project is responsible for the project distribution directory and must be able to account for its entire contents.

After uploading to the canonical distribution channel, the project (or anyone else) may redistribute the artifacts in accordance with their licensing through other channels.

All official releases MUST be archived permanently on https://archive.redwax.eu.