Child pages
  • Bug Fix and Release Policy

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This document describes the process for how and when bug fixes will be published in any released versions of sipXecs:

Release Procedure

Products go through varying procedures to get released.  It’s important to understand our terminology when communicating outward.  From a 50,000 foot view, the different stages look like:

...

SF binaries: http://download.sipfoundry.org/pub/stage

Release Policies

  1. Source code submissions will have to pass the requirements listed the section Source Code Submission Requirements and Policies below

  2. Version number will not change. Example: Release 1.2.3 will remain 1.2.3. Each rpm will have a release number that will increment so you will be able to identify when a file is newer. See Version Numbers for more info.
  3. Change log will be published describing each bug fix stating explicitly the impact of the bug fix. Administrators should be able to easily decide if and/or when they need to install the update. TBD: how to build change log and where to publish?
  4. ISOs will not be rebuilt for each bug fix. Building ISOs is easy, but testing each of the ISO is not. As a general rule, administrators would be required to install the last released ISO and run yum update to get the latest bug fixes. This is the same policy Linux distributions like CentOS and Fedora follow.
  5. After a bug fix is made to source code repository and binaries have been built but before binaries have been published to download.sipfoundry.org, the binaries will be made available for a verification process. There will be a simple installation process any customer can do to install the build and verify bug fix. Once the fix has been verified and published to download.sipfoundry.org, customer's system will not require another update.
  6. When a bug fix release is uploaded to download.sipfoundry.org the previous RPMs will no longer be made available for download. Having hundreds of repositories is simply not feasible. It is recommended you keep a local copy of the RPMs you've installed into production should you need them.

Source Code Submission Requirements and Policies

  1. Source code for bug fixes will be rejected if they would restrict administrators from using any other set of binaries in the same major.minor version scheme.
  2. Contributors will be required to sign a contri
  3. Each source code fix made to a released branch will go through a code review process by a predetermined team. The team will look for validation of the fix, but more importantly look for regressions or areas the could cause system crashes. If a code fix can be refactored to be safer, then it will be recommended as such.
    1. Release 4.4.0 Source code Review Team: George Niculae, Joegen Baclor, Douglas Hubler