Version 23 (modified by fitz, 10 years ago) (diff)


BCCD Releases

The BCCD release schedule is principally based on a "when it's ready" mentality. New versions are released once bug fixes or features are complete and tested for functionality. While we cannot dictate exactly when new versions will appear, we can define the process by which new releases come about.

Each BCCD version number maintains the form X.Y.Z, where X corresponds to significant or fundamental changes, Y corresponds to changes that "add" something, and Z corresponds to changes that "fix" something. Each new version has a corresponding milestone in the BCCD Trac, with which there will be some number of associated tickets. Once all tickets within a milestone are closed a new release will be tagged, a set of ISOs will be generated, and the previous releases will be archived. After being archived, an old build has the potential not to be hosted anymore. That said, the source for every version will still be kept in the repository, making it easy to rebuild an older version if ever necessary.

Additionally, once a day, a set of ISOs will be generated from the source in trunk at that given moment. These nightly snapshots provide a way for users to play around with the bleeding-edge version of the BCCD and give feedback to the developers on what may or may not be working. Any given nightly snapshot is only available for 24 hours, as it will be overwritten by the subsequent day's build. As such, any bug report must reference the revision number and the day of the build. This information is easily accessible via the command bccd-version shipped within the ISOs.

It is the Release Engineer's duty to ensure that when a new release is being built, that only those tickets referenced by that version's milestone are being released. In order to enforce this and simultaneously allow active development to continue, a temporary branch will be created for the new version and put under a code freeze while changes are verified and tested. These branches will follow the numbering convention "X.Y.ZrcN" where "rc" is short for "release candidate" and N is an integer standing for which release candidate the branch is. After the release candidate is verified, the release branch and associated builds are created.

With the process described above, each release can be traced down to a well-defined set of changes and therefore make it easier for users to know what's happening and for the developers to know exactly what each release means.

Questions, comments, or concerns about this process should be sent to bccd-developers -at-