...
A build that contains features that are still in development and slated for an upcoming 4.6 release. Features or bug fixes that make "large" changes are developed on separate code (git) branch called a "feature branch" away from all other code. Once they pass a certain level of testing, then the branch is merged into the Stable branch. This allows features to be integrated with the rest of the system code when they are determined to be in a stable state.
Unstable build code is available to customers for testing from the following binary repositories:
SF binaries: http://download.sipfoundry.org/pub/release-4.6.0-unstable/
Look for repo with 'unstable' after the version number.
Explanation of Stable:
Stable builds are essentially the precursor to a Release Candidate. These builds represent the most stable code produced by development to their knowledge. The Stable build includes all bug fixes and any features that have passed an initial testing process. The fixes and features may not however been tested with the system as a whole.
Stable build code is available to customers for testing from the following binary repositories:
SF binaries: http://download.sipfoundry.org/pub/release-4.6.0-stable/
Look for the repo with 'stable' after the version number.
Explanation of Release Candidate:
...
Release Candidate code is available to customers for testing from the following binary repositories:
SF binaries: http://download.sipfoundry.org/pub/stage/4.6.0
Release Policies
Source code submissions will have to pass the requirements listed the section Source Code Submission Requirements and Policies below
- 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.
- 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?
- 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.
- 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.
- 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.
...