Changes between Version 25 and Version 26 of WikiStart


Ignore:
Timestamp:
Jun 18, 2015 7:06:01 PM (4 years ago)
Author:
skylar
Comment:

removing out-dated info

Legend:

Unmodified
Added
Removed
Modified
  • WikiStart

    v25 v26  
    44        For more information, please check out the [http://bccd.net website] or, for documentation, the [http://bccd.net/ver3/wiki wiki].
    55
    6 
    7 = BCCD Releases =
    8 
    9         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.
    10 
    11         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.
    12 
    13         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.
    14 
    15         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.
    16 
    176        Questions, comments, or concerns about this process should be sent to bccd-developers -at- bccd.net.